Download (direct link):
So, this method would not work for us. This left us with one option left for an EJB solution. The stateless session bean seemed like the least likely solution, because the name implies that it lacks state. Or does it?
Stateless Session Bean
By process of elimination, we were left with the stateless session bean approach. The stateless session bean does not track any context between requests. The practical use is to allow the EJB container to provide a highly scalable solution to handling client requests. The container creates a pool of beans to handle the number of requests being received by the container.
The key concept is that the container can assign a stateless session bean to handle any client request, without guaranteeing that the next request by the same client will get the same bean. This allows for much more efficient resource allocation.
t5«EJBRemoteMethod>> search(searchString : String) : java.util.ArrayList
C?EJB_Context: javax.ejb.SessionContext = null Ł thelndex : Index
Stateful EJ BO <5ejbRemoveO : void CjejbActivateO : void *^?ejbPassivate() : void
*^?setSessionContext(sc : javax.ejb.SessionContext) : void <5 «EJB Create Method» ejbCreateO : void
<3«EJBRemoteMethod» search(searchString : String) : java.util.ArrayList
Figure 43.4 The Stateful EJB class diagram.
The Stateful Stateless Session Bean 369
370 Item 43
Frequently overlooked in this scenario is that a stateless session bean can contain member variables that are independent of the client request. Figure 43.5 is a class diagram of a stateless session diagram, called Stateless.
This shows the member variable called thelndex, which is populated at initialization when the create() method is called on the home interface. After that, requests can be executed by calling the search() method on the remote interface.
But the obvious question arises. Isn't every client calling the create() method? If so, doesn't this give us the same problem? Actually, this is a common misconception. Because EJB relies on indirection through the container, frequently there is confusion with regard to what a given method on the EJB home and remote interfaces actually does before it gets to the EJB implementation. In fact, the call to create() doesn't necessarily mean that the EJB container will create a new stateless session bean. It probably will not, unless this request actually causes the container implementation to determine that it is necessary to create another bean.
This raises an interesting point, though. There is no way to predict or determine how many stateless session beans will be created. Any bean using the member variables needs to take this into account in its design. This becomes even more critical when the container uses clustering.
This means that if we are trying to create a Singleton, or any pattern that demands a resource exists once and only once, this method cannot be used safely.
However, the Singleton pattern and other resource pooling patterns are generally used to ensure the number of instances do not grow out of control. That design goal is achieved implicitly by the design of stateless session beans. They use resource-pooling algorithms to determine the number of session beans that should exist.
Note that this example is not a database connection member variable. In fact, there are certain connection pools that are specified in the EJB 2.0 specification. Actually, it is a called a resource manager connection factory, and it entails more than just pooling (deployment, authentication). However, bean developers are required to use the standard ones for JDBC, JMS, JavaMail, and HTTP connections. The container developers are required to provide implementations of these factories.
Remote f's Stateless
<^«EJBRemoteMethod>> search(searchString : String) : java.util.ArrayList
[Jthelndex : Index
CjStatelessEJBO t^ejbRemoveO : void <^ejbActivateO : void tjejbPassivateO : void
<^7setSessionContext(sc : javax.ejb.SessionContext) : void <^7«EJBCreateMethod>> ejbCreateO : void
t^«EJBRemoteMethod>> search(searchString : String) : java.util.ArrayList
Figure 43.5 The Stateless EJB class diagram.
<Ż«Å) Ā Create Method» createQ
The Stateful Stateless Session Bean 371
372 Item 44
These resource manager connection factory objects are part of the movement to the J2EE Connector Architecture, thus fulfilling the third piece of the J2EE paradigm (connectors, along with the current containers and components).
A subtlety in the EJB session bean specification is often overlooked. A large number of developers believe that stateless session beans can maintain no state information at all. This causes confusion on how to maintain instance information that is neutral to any particular request.