Caching data for a timer service
If you want to optimize database access and SQL calls for an EJB timer service, you can enable the application server to cache data for that timer. Caching allows the application server to reuse timer data without having to query the database each time that data is required.
About this task
The specification for enterprise beans requires that an SQL call to the database be made for each call to the javax.ejb.Timer interface, so that the application can ensure that the EJB timer is using the most current data that is available. If these methods are called often, or you have many EJB timers that call any one of these methods, the application server would be generating many SQL statements in a very short amount of time. In some cases, you might find that strict adherence to this requirement is detrimental to performance and causing more overhead than is warranted.
For example, consider a case in which a timer expires only at 12:00 AM every Monday morning. During the course of the week, any applications that call methods on the timer interface will result in the creation of an SQL call, but the call will always return the same data. In addition, when an application calls the ejbTimeout method for a timer, the data that is associated with that timer cannot change; the timer's data that is stored in the database cannot be updated while an ejbTimeout method is running for that timer. Therefore, any subsequent method calls that applications make during the timeout period will cause the generation of an unnecessary SQL call and a wasted trip to the database.
If you enable caching for timer data, however, the application server will only query the database the first time a configured method is called. For any subsequent calls to one of the configured methods, the application server will use the cached data for the life of the timer object, and a new SQL call will not need to be generated.
- When this feature is enabled, your configuration will not be compliant with the EJB specification.
- This feature can lead to the potential for a timer to use stale
data. Cached data for a timer service will become stale after the
next expiration period for the timer has passed.
For example, assume you have a timer that is configured to expire every hour. If you create and save the timer object, the data that the application server caches for that object will only be current for one hour. The cached data would be the same as the data that is stored in the database.
If you call any of the timer methods within the first hour, the timer data is current. After that expiration period, however, the cached data for the timer becomes stale and might not reflect the data that is actually in the database. In this example, if you queried the EJB container for all timers after one and one half hours, the application would get back a new timer object that contains cached data that will be current for thirty minutes; This is because at hour two the timer will expire again, and any cached data stale will then be stale.
Procedure
Example
- App1#EJBJar1.jar#EJBTimer1
- App2#EJBJar2.jar#EJBTimer2
- Example 1
- This example applies caching to all methods, for all timers, and
for all applications.Use one of the following values:
- Using the defaults:
*
- Specifying an integer:
*=127
- Using the defaults:
- Example 2
- This example applies caching to the getInfo method on all timers
for all applications.Use the following value:
*=2
- Example 3
- This example applies caching to the getHandle and getNextTimeout
methods on EJBTimer2.Use the following value:
App2#EJBJar2.jar#EJBTimer2=5
- Example 4
- This example applies caching to:
- the getInfo method on EJBTimer1
- the getNextTimeout and getTimeRemaining methods on EJBTimer2
App1#EJBJar1.jar#EJBTimer1=2:App2#EJBJar2.jar#EJBTimer2=12