If you look at page 510 of the EJB 3.1 specification, then it says that the ability to create timers for stateful session beans may be added in a future version of the specification, so I suspect there are no reasons that are strong enough to stop such a feature.
I can speculate in some reasons that can make timers and stateful session beans a little difficult, but these are just my own speculations and again nothing that cannot be overcome:
- The need to associated a timer to a specific instance of a stateful session bean.
Unlike stateless session beans where a timer can invoke a timeout method on an arbitrary instance from the bean pool, a timer invoking a stateful session bean need to invoke a specific instance. This since they all have an unique state.
- Contention between timer and client.
Since stateful session beans only allow one single thread at a time executing in a bean instance, there may be contention between timer(s) and client associated with a certain bean instance.
For instance, the timer times out and want to invoke a callback method on the bean, but the client has already called the bean. The timer must thus wait until the client call has finished executing.
Udara Amarasinghe wrote:OK so then there is no mechanism to implement stateful bean clients session to finish at specific time.
How about delegating processing of requests to a stateless bean?
Any state information can be enclosed, for instance, as a parameter to the stateless bean.
In the stateless bean you can then use EJB timers.