Amol Katyare wrote:My experience with using EJB Timerservice wasn't good esp. for the reason it seems to be mandatory calling timer.cancel() each time the server is restarted / server crashes. It is absolutely fine for invoking say some batch process at regular interval of time. But as advised in EJB3 in Action, it is ofcourse not a very good option for implementing some real time services which are triggered by timer service. "Quartz" is one of the best appropriate options.
The problem that I faced was, sometimes when server was restarted, I used to get multiple invocation of timeout method successively ignoring what interval I had set. After some analysis, I found the reason. As timer is persisted (I do not know how it is implemented by container), before the code to create timer is actually run, previously persisted instance gets invoked and it disturbs the whole timer cycle. Once fresh timer is started, then it gets regularised. Workaround available is to check if any timer is already running or not then not to create new timer instead use already running one. OR more elegant way is to cancel timer each time you stop server so that regular cycle would be invoked next time you start it up.
1. Does any one have idea how timer is persisted by container (may be in some DB managed by application sever)?
2. I know we can have control over when to hit first timeout() by specifying milliseconds in first argument. But it might be the case I do not want to invoke timeout() before my server is started completely. But how to have control over the persited instance of the timer and how to refrain it from hitting timeout() unless server is started?
You showed up just in time for the waffles! And this tiny ad:
Building a Better World in your Backyard by Paul Wheaton and Shawn Klassen-Koophttps://coderanch.com/wiki/718759/books/Building-World-Backyard-Paul-Wheaton