Timer are persisted

[Deepika Joshi]

I read following in EJB 3 in Action,

Timer are peristed unlike SLSB & MDB (even if container is re-started)

my confusiom is that is a bean SLSB instance is crashed, will created timer for a bean survive?
if bean instance is not there what is the use of timer?

Can someone explain it - Timer are peristed

thanks.

[Anish Mathur]

The EJB Timer Service is a container-provided service. Timer Service creates timers which call SLSB timout callback method.
Timers are not associated with a particular SLSB instance, as SLSB timeout callback method is called by container, if the bena crashes container can call the timeout on another bean instance.

Timers are managed and persisted by the container.
HTH
Anish Mathur

[Deepika Joshi]

Thanks

[Amol Katyare]

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.

My questions

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?

Thanks,
Amol.

[Marcin Faryna]

hi, I dont't know which EJB container do you use, but from spec "An EJB 3.0 container must make the following APIs available to the enterprise bean instances at runtime:
• Java 2 Platform, Standard Edition v5 (J2SE) APIs, which include the following APIs:
• JDBC
• RMI-IIOP
• JNDI
• JAXP
• Java IDL
• EJB 3.0 APIs, including the Java Persistence API
• JTA 1.1, the UserTransaction interface only
• JMS 1.1
......"
so i think it's bug in implementation when bean serve business request without container services fully initialized.
Container must be fully operational before bean can serve business request (Timeout for example). This is my point of view of course.

[Dhiraj Mahapatro]

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.

My questions

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?

Thanks,
Amol.

EJB Timer Service, is generally not preferred in real time arenas in Business. When there is an option of customized cron job, people hardly opt for EJB timers.

Coming to your question:

1. Does any one have idea how timer is persisted by container (may be in some DB managed by application sever)?

Ans: If you take into consideration Websphere Application Server, the timer is persisted to a Cloudscape database associated with the server process. The default Data Source JNDi Name is jdbc/DefaultEJBTimerDataSource.
Tables used are TASK, TREG, LMGRand LMPR. A string EJBTIMER_ is prepended to these tables. These tables are created during server start if they do not exist. Multiple independent EJB timer services can share the same database if each instance specifies a different prefix string.


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?

Ans: You can also set a poll interval which will specify the server (once started) to poll this Cloudscape database and get the timer information and execute the timeouts.

[Dhiraj Mahapatro]

In case of JBoss: It will try to create a TIMERS table in the datasource it is configured to use (by default this is DefaultDS which points to a HSQL database in the data directory)