Configuring Enterprise JavaBeans timer service

For non-persistent Enterprise JavaBeans (EJB) timers, you can configure the interval between timer retries and the number of retry attempts for failed calls to the timeout callback method.

About this task

You can configure the EJB timer service to use a ContextService instance to control which managed thread contexts are propagated to or created on the non-persistent timer thread.

The EJB timer service retries failed calls to the timeout callback method for non-persistent timers every 5 minutes until the timeout callback method completes successfully. Use the following options to configure non-persistent timers.

Maximum number of retries

This option specifies the maximum number of times that the failing timeout callback method can 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 specification-compliant. A value of 1 or greater indicates the specific number of retries that are allowed.

This option is useful for applications that do not require non-persistent timers to complete at each of the scheduled times. For example, suppose an application creates a non-persistent interval timer that is scheduled to run every 5 minutes. If you configure the number of retries to 0, the timer runs one time every 5 minutes, regardless whether it succeeds or fails.

Time interval between retries

This option 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.

This option is useful when you want the timeout callback method to complete before the scheduled time, when using a smaller retry interval. This approach is also applicable for applications where it is acceptable to delay the timer completion to a later time, such as when using a later retry interval, to enable the timeout callback method to have a better chance to run successfully.

The EJB timer service establishes the specification-required Transaction, ClassLoading and JEE MetaData contexts on the non-persistent timer thread. The following option may be used to configure other contexts to be propagated or created on the non-persistent timer thread:

Non-persistent timer method context propagation reference: This option specifies the context service that is used to manage context propagation to non-persistent timer method threads. Specifying the context service with this option enables propagating the z/OS WLM context and the security context to the non-persistent timer thread.

Procedure

Configure the application server to include an EJB feature that supports non-persistent timers in the server.xml file.
For example, add the following to the server.xmlfile:
```
<featureManager>
     <feature>ejbLite-3.2</feature>
</featureManager>
```
If you are configuring context propagation, add the following code to the server.xml file:
```
<featureManager>
     <feature>ejbLite-3.2</feature>
     <feature>concurrent-1.0</feature>
</featureManager>
```
Configure the EJB timer service to use specific maximum number of retry and retry interval values for non-persistent timers in the server.xml file.
For example, use the following configuration to specify that the non-persistent timers retry up to three times, with 10 seconds between retries:
```
<ejbContainer>        
     <timerService nonPersistentMaxRetries="3" nonPersistentRetryInterval="10"/>
</ejbContainer>
```
With this configuration, the timeout callback method for a timer can be called up to four times. The first call occurs at the scheduled time. If the first call fails, then the first retry occurs immediately after the failure. If the timeout callback method continues to fail, then the second and third retries occur 10 and 20 seconds later, respectively.

In the following example, a failed timeout callback method is only retried one time. The callback interval is irrelevant since the first retry is always performed immediately.
```
<ejbContainer> 
     <timerService nonPersistentMaxRetries="1"/>    
</ejbContainer>
```

Example

In the following example, the security context is propagated to programmatically created non-persistent timers.

<contextService id="EJBTimerContextService">
    <securityContext/>
</contextService>

<ejbContainer cacheSize="1024">
    <timerService nonPersistentMaxRetries="0"
      nonPersistentContextServiceRef="EJBTimerContextService">
    </timerService>
</ejbContainer>