Develop read-only entity beans
Overview
This function is an addition to the existing EJB caching options. You are most likely to want to use it under the following conditions:
- Your application uses data that change relatively infrequently. An example might be a retailing application that uses pricing data that only changes once a week or month.
- Your application can tolerate data that may be stale. The degree of “staleness” that the EJB container allows is configurable by the user.
- The bean is coded in a thread-safe manner, so it can safely be invoked by multiple threads at once.
To use this function, you declare the bean type as read-only the same way you currently select the bean caching options, through a selection list within the application assembly tooling (either WebSphere Application Developer or the Application Server Toolkit).
Procedure
- Start your assembly tool.
- Call up the parameter selection list as you normally do.
- Set the Activate At parameter to ONCE. This is the same as for standard option A caching.
- Set the Load At parameter to either INTERVAL, DAILY, or WEEKLY.
- INTERVAL
- causes the bean to be reloaded if a certain time interval has been exceeded since the last time the bean was loaded.
- DAILY
- causes the bean to be reloaded on the first business method invocation that occurs after a specified time on the host computer's local time-of-day clock.
- WEEKLY
- is similar to DAILY except it occurs once per week at a specified time.
- Set the Reload Interval parameter to a nonnegative integer value. The meaning of this parameter depends on whether the Load At parameter is INTERVAL, DAILY, or WEEKLY.
- INTERVAL
- the integer represents the number of minutes that can elapse (since the last time the bean was loaded) before the EJB container reloads the bean’s state from persistent storage. A value of 0 is permissible and causes the container to never reload the state of the bean.
- DAILY
- the integer represents an absolute time each day that the reload is performed after, expressed in what is commonly called the 24-hour clock. That is, a whole number between 0000 and 2359, where 0000 represents midnight, 1200 represents noon, and 2359 represents one minute before midnight. Any leading zeroes on this number are optional. In the case of malformed values (for example, 1285), the resulting clock time is always computed by taking the minutes value from the two least-significant digits and adding that to the hour value taken from the digit or digits to the left of the two least-significant ones. Thus, a value of 1285 will be interpreted as 1325 (85 minutes after 1200). Any values exceeding 2359, as well as negative or nonnumeric values, are interpreted as 0000.
- WEEKLY
- the integer is encoded in the same manner as daily, except it must be five digits in length, the first digit representing the day of the week. Sunday is encoded as 1 and Saturday is encoded as 7. If the value is four digits or less, it is treated as if it were five digits long with the first digit being 1.
Reloading is performed only in response to a business method invocation on the bean. When a business method is invoked, the EJB container checks to see whether either the reload interval time has expired or the absolute clock time for that day has passed (depending on whether INTERVAL, DAILY or WEEKLY was used). If so, the container reloads the bean state.
When a read-only entity bean is invoked within a global transaction, and the reload interval expires while the transaction is active, business method calls on the bean during that transaction continue to see the non-reloaded state of the bean for the duration of that transaction. That is, a snapshot of the bean state is effectively taken on the first business method invocation on that bean during a transaction, and that state continues to be in effect for that transaction until it completes. New invocations on that bean performed in a different transaction, after the reload, see the reloaded state.
See also
Example: read-only entity bean