Session beans can be implemented in one of the following state management modes ” stateless or stateful . The following sections discuss these bean types, their distinct differences, and their use in applications. Stateless Session BeansStateless session beans contain no conversational state between methods for a specific client. When a client calls a method on a stateless session bean, the bean's instance variables can contain state, but only for the duration of the call. When the method has completed, the bean instance no longer retains the state. The stateless bean instance can, however, hold state, but its state is not guaranteed to be specific to a calling client. For example, instance variables of a stateless bean instance can include an open database connection or an object reference to an EJB object. However, when stateless bean instance are not involved in servicing a client-called method, they are all considered identical from the client's perspective. Hence, there is no fixed mapping between clients and stateless instances. This allows the EJB container to delegate a client-called method to any available stateless bean instance. For example, the EJB container can delegate requests from the same client within the same transaction to different instances of the stateless bean between remote method calls. In general, an EJB container needs to retain only the number of stateless bean instances required to service the current client load. Because of client "think time," the number of stateless session beans is usually much smaller than the number of active clients. The EJB container typically tries to minimize the resources needed to support stateless session bean clients by creating and destroying the bean instance on an as-needed basis. Note WebLogic Server can pool identical EJBs, such as stateless session beans and message-driven beans, increasing the J2EE application's scalability and performance. When to Use Stateless Session BeansStateless session beans are commonly used for procedural tasks that can be accomplished in a single client request. These tasks are sometimes referred to as Model Reuseable Service Objects ”any business object providing a generic type of services to its clients. A typical example is a business task that requires returning a list of books by author. Likewise, an application requiring workflow or state management could be modeled with stateless session beans. This application might require chaining session beans to accomplish the task. Chaining stateful session beans becomes a problem when one of the session beans times out or generates an exception. For instance, if three stateful session beans are chained together and the second one in the chain times out, the state trailing the second bean instance would be lost. Because stateless session beans do not maintain conversational state, losing state would not be an issue. The EJB container would simply assign another bean instance without the client being aware of the transition. Also, the Facade pattern is based on session beans providing a higher-level entry point into a system; what transpires in the subsystem is hidden from the client. This allows the client to access an object's method at the entry point, thus enabling the method to carry out all underlying tasks in the subsystem. It is important to model session beans as a Facade pattern to take advantage of performance efficiencies. Because EJBs are remote objects, it is best for the client to call only the unified interface to the system, thus reducing the number of remote calls. Having session beans call individual EJB objects might not result in a remote call, as WebLogic Server is optimized to make local method calls instead of remote calls when possible. Stateful Session BeansStateful session beans are similar to stateless session beans, except they contain conversational state on behalf of a specific client; this state must be retained across invoked methods and transactions. A stateful session bean retains a client's conversational state by storing the state as attributes of the bean. It is the EJB container's responsibility to ensure that subsequent method calls by a client are routed to the same instance of a stateful bean. Stateful session beans are memory consumers because state has to be maintained within the bean instance. Therefore, to efficiently manage stateful session beans, the EJB container might need to temporarily transfer the state of an idle stateful session bean instance from memory to disk. This transfer is called instance passivation . The transfer back to memory is called activation . The container can passivate a stateful session bean instance only when the instance is not in a transaction. Note A session object's conversational state might contain open resources, such as open database connections. A container cannot retain these open resources when a session bean instance is passivated. The session bean developer must close and open resources in the ejbPassivate() and ejbActivate() methods. When to Use Stateful Session BeansStateful session beans are appropriate in the following application situations:
For example, a client's interaction between the browser and the Web server follows the request/response model. Because HTTP is considered connectionless and stateless, after the server has responded to the client's request the connection is dropped and forgotten. Using stateful session beans in a Web-based application provides a mechanism for storing the client's interaction with the server. A shopping cart in an e-commerce Web site is a good example of using stateful session beans. Other examples include an ATM account transfer application, an airline reservation system, and an online book store. Differences Between Stateless and Stateful Session BeansEven though the major difference between stateless and stateful sessions beans is based on maintaining conversational state between the client and the bean instance, Table 20.1 compares the primary characteristics of these two bean types. Table 20.1. Comparing Stateless and Stateful Session Beans
|