Entity bean
Most external clients access WebSphere services through session beans, but it is possible for an external client to access an entity bean directly. Furthermore, a session bean inside WebSphere is itself often acting as a client to one or more entity beans also inside WebSphere; if load-distribution features are used between that session bean and its target entity bean, then the same questions arise as with plain external clients.
Strictly speaking, 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. But it is common for one client to make a succession of requests targeted at the same entity bean instance. Unlike all the previous cases, it is possible for multiple independent clients to access the same entity bean instance more or less concurrently. Therefore, it is important that the state contained in that entity bean be kept consistent across the multiple client requests.
For entity beans, the notion of a session is more or less replaced by the notion of transaction. For the duration of one client transaction to which it participates, the entity bean is instantiated in one container (normally the container where the first operation within that transaction was initiated). All subsequent accesses to that same bean, within that same transaction, must be performed against that same instance in that same container.
In between transactions, the handling of the entity bean is specified by the EJB specification, in the form of a number of caching options:
- With option A caching, WAS 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 clustered or participate in workload management if option A caching is used.
- With option B caching, the bean instance remains active (so it is not guaranteed to be made passive at the end of each transaction), but it is always 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.
- With option C caching, (which is the default), the entity bean is always reloaded from the database at the start of each transaction and made passive at the end 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 effectively similar to the session clustering facility described for HTTP sessions: the shared state is maintained in a shared database, and can be accessed from any server when required.
WebSphere is a trademark of the IBM Corporation in the United States, other countries, or both.
IBM is a trademark of the IBM Corporation in the United States, other countries, or both.