Configuring the enterprise JavaBeans timer service for persistent timers
For persistent EJB timers, you can configure the EJB timer service to control the data source where the timers are stored, the interval between timer retries and the number of retry attempts for failed calls to the timeout callback method.
About this task
When the ejbPersistentTimer feature is enabled, a data source must be configured for persisting the timers or any attempt to use persistent timers fails. The EJB timer service uses the DefaultDataSource if it is configured and no other specific data source is configured for use by the EJB timer service.
Also, the EJB timer service retries failed calls to the timeout callback method for persistent timers every 5 minutes until the timeout callback method completes successfully.
Use the following options to configure persistent timers.
- EJB Persistent Timers Scheduled Executor
Specifies a reference to a persistent executor that controls the behavior of persistent timers. A default instance, defaultEJBPersistentTimerExecutor, is provided which uses the DefaultDataSource as the persistent store. The EJB persistent timers scheduled executor reference might be changed to a custom configuration, or the default instance might be overridden to change specific values. The following options are available for the persistent executor:
- Retry limit
Specifies the maximum number of times that the failing timeout callback method might be retried. If the timeout callback method is successful upon retry, the server stops attempting to run it. If a retry fails, the server continues to attempt retries until the timeout callback method succeeds, or the retry limit is reached. After the retry limit is reached, the server does not attempt to run the timeout callback method, even if prior attempts did not succeed. The default value of -1 indicates unlimited retries. A value of 0 indicates no retries, and is not compliant with the EJB specification. A value of 1 or greater indicates the specific number of retries.
Changing the configuration of the number of times a timeout callback method is retried for non-persistent timers is useful for applications that do not require non-persistent timers to complete at each of the scheduled times. For example, if an application creates a non-persistent interval timer that is scheduled to run every 5 minutes, then configuring the number of retries to 0 results in the timer, running one time every 5 minutes, regardless of whether it succeeds or fails.
- Retry interval
Specifies the interval between retry attempts for a failed timeout callback method. The first retry always occurs immediately, regardless of the interval that is configured for this value. All additional retries wait for the interval that is specified for this value. A value of 0 indicates that all retries are immediate. A value of 1 or greater indicates that retries must wait for that specific number of seconds. The default is 300 seconds.
Configuring a different time interval between retries for non-persistent timers is useful for applications where it is important for the timeout callback method to complete before the scheduled time. This approach is also applicable for applications where it is acceptable to delay the timer completion to a later time, such as a later retry interval, to enable the timeout callback method so the application can have a better chance to run successfully.
- Persistent Task Store
Specifies which data source is used. A default instance, defaultDatabaseStore, is provided which uses the DefaultDataSrouce as the persistent store.