WAS v8.5 > Administer applications and their environment > Welcome to administering EJB applications > Configure a timer service

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 that an SQL call to the database be made for each call to the javax.ejb.Timer interface, so the application can ensure 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 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:

  1. In the application server's dmgr console, select the server to configure. Click Servers > appservers > 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 the 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 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 you 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

    Specifies the getHandle() method

    2

    Specifies the getInfo() method

    4

    Specifies the getNextTimeout() method

    8

    Specifies the getTimeRemaining() method

    16

    Specifies the getSchedule() method

    32

    IsPersistent() method

    64

    IsCalendarTimer() method

    We can apply this property to any individual methods listed above 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 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 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:

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:

  • Using 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


Related


Configure a timer service
Configure a timer service for network deployment


Reference:

Example: Using the Timer Service with the TimedObject interface
EJB timer service settings


+

Search Tips   |   Advanced Search