Enterprise JavaBeans 3.1, 6th Edition

Chapter 7. The Singleton Session Bean

So far, we’ve enjoyed the isolated invocation context provided by stateless and stateful session beans. These bean types service requests independently of one another in separate bean instances, relieving the EJB developer of the burden introduced by explicit concurrent programming. Sometimes, however, it’s useful to employ a scheme in which a single shared instance is used for all clients, and new to the EJB 3.1 Specification is the singleton session bean to fit this requirement.

Contrary to most late-generation feature additions, the singleton is actually a much simpler conceptual model than we’ve seen in SLSB and SFSB, as shown in Figure 7-1.

Figure 7-1. All invocations upon a singleton session bean using the same backing instance

Here all client requests are directed through the container to a sole target instance. This paradigm closely resembles that of a pure POJO service approach, and there are quite a few repercussions to consider:

• The instance’s state is shared by all requests.

• There may be any number of requests pouring through the instance’s methods at any one time.

• Due to concurrent invocations, the EJB must be designed as thread-safe.

• Locking or synchronization done to ensure thread safety may result in blocking (waiting) for new requests. This may not show itself in single-user testing, but will decimate performance in a production environment ...