This week's giveaway is in the Spring forum. We're giving away four copies of liveProject: Protecting User Data with Spring Security and OAuth2 and have Laurentiu Spilca on-line! See this thread for details.
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.