InfoCenter Home >
7: Multimachine management >
7.1: Using WebSphere Application Server in a multimachine environment >
7.1.6: Managing state >
7.1.6.2: EJB sessions and transaction affinity

7.1.6.2: EJB sessions and transaction affinity

When an EJB client interacts with one or more enterprise beans, the WebSphere Application Server container manages the state information associated with a series of client requests. Whether session state is managed at all depends on the types of enterprise beans that participate in fulfilling these requests. Each type of enterprise bean is handled differently by the container.

Stateless session bean

By definition, a stateless session bean maintains no state information. Each client request directed to a stateless session bean is independent of the previous requests that were directed to the bean. The container maintains a pool of instances of stateless session beans, and provides an arbitrary instance of the appropriate stateless session bean when a client request is received. Requests can be handled by any stateless session bean instance in any clone of the application server, regardless of whether the bean instance handled the previous client requests.

Stateful session beans

A stateful session bean is used to capture state information that must be shared across multiple consecutive client requests that are part of a logical sequence of operations. The client must obtain an EJB object reference to a stateful session bean to ensure that it is always accessing the same instance of the bean.

WebSphere Application Server supports the cloning of stateful session bean home objects among multiple application servers. However, it does not support the cloning of a specific instance of a stateful session bean. Each instance of a particular stateful session bean can exist in just one application server and can be accessed only by directing requests to that particular application server. State information for a stateful session bean cannot be maintained across multiple application server clones.

Entity beans

An entity bean represents persistent data. Most external clients access entity beans by using session beans, but it is possible for an external client to access an entity bean directly. The information contained in an entity bean is not usually associated with a session or with the handling of one client request or series of client requests. However, it is common for a client to make a succession of requests targeted at the same entity bean instance. It is also possible for more than one client to independently access the same entity bean instance within a short time interval. The state of an entity bean must therefore be kept consistent across multiple client requests.

For entity beans, the concept of a session is replaced by the concept of a transaction. An entity bean is instantiated in a container for the duration of the client transaction in which it participates. All subsequent accesses to that entity bean within that transaction are performed against that instance of the bean in that particular container. The container needs to maintain state information only within the context of that transaction. The workload management service uses the concept of transaction affinity to direct client requests, After a server is selected, client requests are directed towards it for the duration of the transaction.

Between transactions, the state of the entity bean can be cached. The EJB container supports both option A and option C caching.

  • With option A caching, WebSphere Application Server assumes that the entity bean is used within a single container. Clients of that bean must direct their requests to the bean instance within that container. The entity bean has exclusive access to the underlying database, which means that the bean cannot be cloned or participate in workload management if option A caching is used.
  • With option C caching (the default), the entity bean is always reloaded from the database at the beginning of each transaction. A client can attempt to access the bean and start a new transaction on any container that has been configured to host that bean. This is similar to the session clustering facility described for HTTP sessions, since the entity bean's state is maintained in a shared database that can be accessed from any server when required.
Go to previous article: HTTP sessions, servlets, and the session manager Go to next article: Server affinity

 

 
Go to previous article: HTTP sessions, servlets, and the session manager Go to next article: Server affinity