EJB caching and failover

An entity bean represents persistent data. 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 concurrently. The state of an entity bean must be kept consistent across multiple client requests.

Within a transaction, the WLM ensures that the client is routed to the same server. Between transactions, the state of the entity bean can be cached. WebSphere V5.0 supports Option A, Option B, and Option C caching.

Entity beans can be workload managed if they are loaded from the database at the start of each transaction. By providing either Option B caching or Option C caching (the default), entity beans can participate in WLM. These two caching options ensure that the entity bean is always reloaded from the database at the start of each transaction. See 6.2.3, Entity beans for a detailed description of the three caching options.

Please note that WebSphere V5 also supports the optimistic concurrent control, where the cached data is checked and a collision is detected during the commit stage. Loading data from the database may not be required at the transaction start if the application design is in place to stamp cached entity beans.

  Prev | Home | Next

 

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.