Stateful Session Beans are the least use type of EJBs. I saw a few usages of Stateful Session Beans but most of them were improper. Stateful Session Beans are the least understood type of EJBs. What are they for? Or better: show me use cases where Stateful Session Beans are essential solution! The internet gives several answers but not always proper. We will investigate those answers.
Singleton is the only type of Session Beans that admits concurrent access. This way bottlenecks are avoided. There are two manners of synchronizing access, bean synchronization and container synchronization. Default is container managed synchronization. We spare a few words on container managed synchronization.
- An application need to read configurations from an external source, for instance a file
- A configuration file might be changed during an application’s work
If EJB instance, other than Singleton, throws system exception, which is non application runtime exception, then EJB Container immediately discards the instance without calling @PreDestroy method.
This is not a problem if calling @PreDestroy is not essential to an application. If it is, then it was proposed to provide additional application pool of resources or beans and periodically clean up abandoned resources or beans. We do it other way.
- Application need to access Non-Managed Resource, for instance a plain TCP Connection
- Resources are heavily used
- To producing Resource, for instance to establish a TCP Connection and application-specific initialization, is time consuming
- Operations on Resources are stateless and nontransactional
Local EJB can be accessed by clients from the same application. But not only. The EJB specification admits that a local EJB can be accessed by any client from the same JVM. It is up to EJB Container provider if it allows such invocations. Fragment of EJB 3.1 specification: