Re: Thread Management / ClockDaemon

[Brendan W . McAdams]

On this token, talking to Alan Cabrera and Jeremy Boynes on Freenode, 
the question came up about why not just use java.util.Timer; having 
looked at it java.util.Timer under 1.4 (We just moved to 1.4 at work 
from 1.3 so i'm still not up to speed on the API changes - I hadn't 
realised how much Timer had changed) it certainly is a closer 
functional match for the needs of EJB timers [clockdaemon provides no 
way to check next execution time].

One obvious benefit to ClockDaemon is it's ThreadPool is configurable 
and conceivably Geronimo could set one that it can control, however 
ClockPool currently isn't giving it a managed ThreadPool, and 
java.util.Timer as long as EJBTimerService only uses a signle instance, 
will only use one thread which can be 'controlled' from 
EJBTimerService.

For the time being, pending peer review I'm going to give this some 
effort with java.util.Timer as the backing timer until we can come up 
with something better.

-Brendan
On May 18, 2004, at 16:12, Brendan W.McAdams wrote:
I'm looking over some more of my design with regards to the EJB 2.1 
timer service, and looking at using ClockDaemons as provided by the 
ClockPool service in o.a.g.system.  Are there any issues I should keep 
in mind working with this?  Are the threads it kicks off cleanly 
managed? (I do notice we're setting an explicit threadpool on the 
clockdaemon within clockpool).

Am I safe using the ClockPool service for this task?
Regards,
Brendan