Session Bean Types


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 Beans

Stateless 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 Beans

Stateless 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 Beans

Stateful 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 Beans

Stateful session beans are appropriate in the following application situations:

  • The need to maintain client state ” Stateful session beans enable you to maintain conversational state about a specific client, so they can be used whenever a server-side business object has to represent client state information. However, because each stateful bean is tied to a client request (unlike stateless beans), it cannot be pooled, so be careful when using stateful session beans.

  • Representing workflow scenarios ” Business objects that manage the interaction of modules or submodules across a transaction can easily be represented as stateful beans. These objects are usually tied to a single client request and must maintain state information; these characteristics are typical of a stateful EJB.

  • Represent short-lived, nonpersistent objects ” Unlike entity beans, stateful beans are not persistent and generally live for the lifetime of the client request to which they are attached. They cannot be re-created after the client's session with the server is over, and even a server failure can force the death of stateful session beans.

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 Beans

Even 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

Stateless Session Bean

Stateful Session Bean

Maintains no state.

Maintains state.

The same stateless session bean within the same home has the same object identity, which the container assigns .

Has a unique identity that the container assigns at create time.

Holds no conversational state between methods for a specific client, so it can be pooled.

Holds conversational state between methods for a specific client, so it cannot be pooled.

Not bound to a single client request.

Bound to a single client request.

Does not make use of passivation and activation.

Passivation and activation are intricate parts of its behavior.

Cannot implement the SessionSynchronization interface.

Can make use of the SessionSynchronization interface to synchronize conversational state.

No caching of conversation state. Can cache object state.

Can cache conversational state.

Commonly used for business logic and workflow.

Commonly used for shopping carts.



BEA WebLogic Platform 7
BEA WebLogic Platform 7
ISBN: 0789727129
EAN: 2147483647
Year: 2003
Pages: 360

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net