Network Deployment (Distributed operating systems), v8.0 > Administer applications and their environment > Administer EJB applications > Configure a timer service
Cache data for a timer service
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. By allowing the application server to cache data for an EJB timer service, you 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 you create that timer object.
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 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, 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 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. 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 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 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
- In the application server's admin console, select the server to configure. Click Servers > Application Servers > server.
- In the Server Infrastructure area, select Java and Process Management > Process Definition.
- In the Additional Properties area, select Java Virtual Machine.
- In the Additional Properties area on the Java Virtual Machine panel, select Custom Properties.
- 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.
- Enter com.ibm.websphere.ejbcontainer.allowCachedTimerDataForname for the name of the custom property.
- Determine the best value for your needs and environment. The value for this property allows you as much control over caching as you need. We can specify a wildcard or use specific timer names, and you can fine tune control over which methods are cached by assigning integer values based upon those methods.
These integer values allow you to have precise control over which methods you allow to use cached data. Integers are assigned on a per bean basis or to all beans if you use an asterisk (*). The integer values and their corresponding methods are:
- 1
- GetHandle() method
- 2
- GetInfo() method
- 4
- GetNextTimeout() method
- 8
- GetTimeRemaining() method
- 16
- GetSchedule() method
- 32
- IsPersistent() method
- 64
- IsCalendarTimer() method
We can apply this property to any individual methods listed above by using the assigned integer value, or you 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 you could not specify an integer. The default behavior when this property is set is to apply caching to all methods.
When you 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 you 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 you 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
- Select OK.
- 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. Use 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
Related
Example: Using the Timer Service with the TimedObject interface
EJB timer service settings