Caching data for a timer service

To optimize database access and SQL calls for an EJB timer service, we 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.

By allowing the application server to cache data for an EJB timer service, we can minimize the number of SQL statements that would be generated for calls to methods on the timer interface. When this feature is enabled, data for the timer will be cached in the timer object when we create that timer object.

The specification for enterprise beans requires 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 we 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, we 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 associated with that timer cannot change; the timer's data 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 we 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.

Be aware of the following conditions:

• When this feature is enabled, the 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 we have a timer configured to expire every hour. If we 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 stored in the database.

  If we 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 containing 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.

Tasks

1. In the application server's administrative console, select the server to configure. Click Servers > Application Servers > server.

2. In the Server Infrastructure area, select Java and Process Management > Process Definition.

3. In the Additional Properties area, select Java Virtual Machine.

4. In the Additional Properties area on the Java Virtual Machine panel, select Custom Properties.

5. Create or modify the com.ibm.websphere.ejbcontainer.allowCachedTimerDataFor custom property.

   • If the property does not exist, click New to create the property.

   • If the property already exists, select the property and click Modify to change the values.

6. Enter com.ibm.websphere.ejbcontainer.allowCachedTimerDataForname for the name of the custom property.

7. Determine the best value for our needs and environment. The value for this property allows you as much control over caching as we need. We can specify a wildcard or use specific timer names, and we can fine tune control over which methods are cached by assigning integer values based upon those methods.

   These integer values allow us to have precise control over which methods we allow to use cached data. Integers are assigned on a per bean basis or to all beans if we use an asterisk (*). The integer values and their corresponding methods are:

   1

   The getHandle() method

   2

   The getInfo() method

   4

   The getNextTimeout() method

   8

   The getTimeRemaining() method

   16

   The getSchedule() method

   32

   The isPersistent() method

   64

   The isCalendarTimer() method

   We can apply this property to these individual methods using the assigned integer value, or we can apply it to a combination of these methods. For example:

   • To apply this property to the getHandle method and the getTimeRemaining method, sum the integer value for the two methods, and use the value 9 (1+8).

   • To apply the property to all seven methods, use the value 127 (1+2+4+8+16+32+64), or we could not specify an integer. The default behavior when this property is set is to apply caching to all methods.

   When we make your decision, use a wildcard to specify all timers, or specify the JNDI names of the timer beans for which the application server will apply caching.

   • We can enter an asterisk (*), which will configure all timers, optionally followed by an integer value - or summation of integer values - that indicate the applicable method on the timer interface. If we do not specify an integer value, the application server will apply caching to all methods.

     For example, the following value applies caching to methods for all timers:

     *
     

   • We can enter the name of the EJB timer bean, optionally followed by an integer value - or summation of integer values - that indicate the applicable method on the timer interface. To enter more than one timer bean, separate each application name with a colon (:). If we do not specify an integer value, the application server will apply caching to all methods.

     For example, the following value applies caching to all methods for MyTimerBean1 and MyTimerBean2:

     MyApp1#MyEJBModule1#MyTimerBean1:MyApp2#MyEJBModule2#MyTimerBean2
     

8. Select OK.

9. Restart the application server.

Example

The following examples demonstrate different ways to implement the caching feature for timer services. Assume that we have two applications, and each application has timers. The timers use the following J2EE names:

• App1#EJBJar1.jar#EJBTimer1
• App2#EJBJar2.jar#EJBTimer2

The examples will show the value to use for the com.ibm.websphere.ejbcontainer.allowCachedTimerDataForname custom property.

Example 1

This example applies caching to all methods, for all timers, and for all applications.

Using one of the following values:

• Use the defaults:

  *
  

• Specify an integer:

  *=127
  

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

Use the following value:

App1#EJBJar1.jar#EJBTimer1=2:App2#EJBJar2.jar#EJBTimer2=12

Configure a timer service

Configure a timer service for network deployment

Example: Using the Timer Service with the TimedObject interface

EJB timer service settings