Transaction affinity
When an enterprise bean 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 or not session state is managed depends on the types of enterprise beans that participate in fulfilling these requests. The container handles each type of enterprise bean differently.
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 cluster member of the application server, regardless of whether the bean instance handled the previous client requests.
When multiple consecutive client requests are part of a logical sequence of operations, a stateful session bean captures state information that must be shared across those requests. 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 clustering of stateful session bean home objects among multiple application servers. However, it does not support the clustering 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 cluster members.
An entity bean represents persistent data. Most external clients us session beans to access entity 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. Throughout the transaction, requests are routed to that instance of the bean in that particular container. Because workload management uses transaction affinity to direct client requests, the container needs to maintain state information within the context of that transaction. After a server is selected, client requests are directed towards it for the duration of the transaction.
Between transactions, you can cache the state of the entity bean. The Enterprise Bean specification defines the following commit options that an entity bean could use. For information on commit options for enterprise beans, see Entity bean assembly settings. 
-
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. When option A caching is used, the entity bean has exclusive access to the underlying database, which means that the bean cannot be clustered or participate in workload management for enterprise beans and application servers.
-
With option B caching, the entity bean instance remains active. As a result, it is not guaranteed to become passive at the end of the transaction. However, the bean is reloaded from the database at the start 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. Beans with option B caching can be clustered.
-
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, because the state of the entity bean is maintained in a shared database that can be accessed from any server when required. Beans with option C caching can be clustered.