Defining bean cache settings for a bean
Bean cache settings are WebSphere Application Server extensions to the Enterprise JavaBeans specification.
To define bean cache settings for an enterprise bean:
Switch to the J2EE perspective.
In the Project Explorer view, right-click the desired EJB module, and select Open With > Deployment Descriptor Editor from the pop-up menu.
On the Beans page of the editor, select a bean and find the Bean Cache section under the WebSphere Extensions section.
In the Activate at field, select one of the following values to specify the point at which an enterprise bean is activated and placed in the cache:
ONCE: Indicates that the bean activates when it is first accessed in the server process, and passivates (and is removed from the cache) at the discretion of the container, for example, when the cache becomes full. If you select to activate at ONCE, then all five of the options listed below are available.
ACTIVITY_SESSION: Indicates that the bean activates and passivates as follows: 1) On an ActivitySession boundary, if an ActivitySession context is present on activation, 2) On a transaction boundary, if a transaction context (but no ActivitySession context) is present on activation, or otherwise, 3) on an invocation boundary.
TRANSACTION: Indicates that the bean activates at the start of a transaction and passivates (and is removed from the cache) at the end of the transaction.
In the Load at field, select one of the following values to specify when the bean loads its state from the database. The value of this setting implies whether the container has exclusive or shared access to the database:
ACTIVATION: Indicates that the bean loads when it is activated (regardless of Activate at setting) and implies that the container has exclusive access to the database.
TRANSACTION: Indicates that the bean loads at the start of a transaction and implies that the container has shared access to the database.
INTERVAL: (For EJB 2.x only) Indicates that the bean loads at intervals, determined by the integer set in the Load at interval field.
DAILY: Indicates that the bean loads its state on a daily basis.
WEEKLY: Indicates that the bean loads its state on a weekly basis.
If you select INTERVAL for the load at field, you then indicate the length of time (in seconds) that the reload occurs. The interval is entered as an integer. The INTERVAL option is only available when Activate at is set to ONCE and Load at is set to INTERVAL; at this point, the reload interval text box is activated.
After you define the bean cache settings, you can click Remove to remove the bean cache settings.
EJB container caching option for entity beans
The Enterprise JavaBeans specification defines three EJB caching options: options A, B, or C. Those options define how the EJB container handles entity bean instances between transactions. EJB caching options are set at the bean level, and are part of the IBM extensions deployment descriptor.
Caching option A
With caching option A, you assume that the entity bean has exclusive access to the underlying persistent store. In other words, between transactions, no one can modify the data. This includes a batch program updating the data, a Java application updating the data, or even the same entity bean running in a different container. This implies option A cannot be used in a clustered environment (WLM). Note that it is your responsibility to ensure no other application will modify the data, as the EJB container has no way to control write access to the underlying database from other servers.
When caching option A is used, the entity bean instance is kept in a memory cache across transactions. At transaction commit, the entity bean attributes are synchronized with the underlying persistent store, and the bean instance remains cached in memory.
Using caching option A can provide some performance enhancements at the expense of higher memory usage. You should only use it if you do not intend to use WebSphere clustering capabilities and you mostly access data in read mode.
To set the EJB caching option A:
Activate at - ONCE
Load at - ACTIVATION
Caching option B
With caching option B, you assume that you have shared access to the underlying database. This means the data could be changed by another application between transactions. When option B is used, the bean instance attributes are always synchronized with the underlying back-end data store at the beginning of every transaction. Similar to Option A, the bean is kept in the cache between transactions.
Caching option B can be safely used in a clustered environment, or when you are not sure if you have exclusive access to data. You are assured that you always work with the last committed data. Option B memory usage is the same as for option A. The performance of both options can slightly differ depending on the nature of your application.
To set the EJB caching option B:
Activate at - ONCE
Load at - TRANSACTION
Caching option C
Similar to option B, caching option C assumes shared access to the database. Unlike option B or A, the bean instance is returned to the entity beans pool at the end of the transaction. A new bean instance is used at the beginning of every transaction.
Caching option C has the best memory usage at the expense of a larger number of methods calls. This is the default behavior.
To set the EJB caching option C:
Activate at - TRANSACTION
Load at - TRANSACTION