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.
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.
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.
*
*=127
*=2
App2#EJBJar2.jar#EJBTimer2=5
App1#EJBJar1.jar#EJBTimer1=2:App2#EJBJar2.jar#EJBTimer2=12
In this information ... | IBM Redbooks, demos, education, and more(Index) |