<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
<br>
<div class="moz-cite-prefix">On 3/12/15 11:29 AM, Tom Zeller wrote:<br>
</div>
<blockquote
cite="mid:CAMNmQDRMfg0gXLigYP=9rLifCbCgJsC-OqO8njZRYY=KtcLu=w@mail.gmail.com"
type="cite">
<pre wrap="">
Agree. My thinking was if we're going to do the work of replacing
Timers, I would tend to reach for Quartz because it allows for more
advanced scheduling, meaning "update metadata everyday at 6am and 6pm
and if the job fails with a remote unavailable exception then
reschedule an hour later and email somebody". And that's overkill and
not really appropriate for things like replay detection.
</pre>
</blockquote>
<br>
That was my initial though too. However in the vein of thinking
outside the box, it occurs to me that our whole notion of component
refreshing is sort of based on the constraints that Timer implicitly
imposes: execution on a fixed, repeating schedule, or a variation
thereof (schedule my own next refresh in X seconds).<br>
<br>
Something like what you describe using a Quartz cron trigger might
actually be pretty useful to some people. Rather than say "refresh
every 8 hours" like now, a more deterministic cron type of schedule
might be more natural for some people and/or use cases.<br>
<br>
Along a different axis: It also occurs to me that our current notion
is that things that are "refreshable" generally refresh themselves
"internally" - they have a Timer instance and they schedule their
own maintenance tasks, or reloads, etc. The alternative way is to
do it "externally", where the jobs are defined elsewhere (e.g
Quartz) and the job simply calls the components external refresh()
method or whatever. Quartz can already easily do that with a nice
Spring bean config. There are design advantages and disadvantages
either way.<br>
<br>
Just some food for thought.<br>
</body>
</html>