EJB timer service settings

The product provides an internal scheduler instance for use by the EJB timer service. The internal scheduler instance is pre-configured for basic EJB timer functions, and provides limited configuration settings for an EJB timer service.

You can specify that you want to use the internal scheduler instance to manage your persistent timer tasks. They are persisted to a Derby database associated with the server process. Selecting this choice precludes the Use Custom Scheduler Instance option.

The internal scheduler instance is the default. Alternatively, a custom scheduler instance might be used.

You can perform a more advanced configuration for the EJB timer service by defining a custom scheduler instance.

A custom Scheduler instance provides more configuration options than the internal EJB timer service pre-configured scheduler instance. You might want to define a custom scheduler instance when running in a clustered environment, allowing all cluster members to run with a single scheduler instance. This definition enables persistent EJB Timers created on one cluster member to run on other cluster members. Providing a custom scheduler instance also enables persistent EJB Timers to be maintained in the same database as other scheduled tasks. Selecting this choice precludes the Use Internal EJB Timer Service Scheduler Instance option.

Specifies the Java™ Naming and Directory Interface (JNDI) name of the data source where persistent EJB Timers are stored for this EJB container. Any data source available in the name space can be used for EJB Timers.

Multiple EJB containers can share a single data source while using different tables by specifying a table prefix.

Specifies an authentication alias to a user name and password that is used to access the data source.

A string prepended to the EJB timer service table names (TASK, TREG, LMGRand LMPR). These tables are created during server start if they do not exist. See the scheduler service for information about manually creating these tables. Multiple independent EJB timer services can share the same database if each instance specifies a different prefix string. If the removeAutomaticEJBTimers command is used to remove timers from a specified scheduler, that scheduler must have a unique table prefix. Otherwise, more timers than expected might be removed.

Specifies the interval at which the EJB timer service daemon polls the database. Each poll operation can be expensive. If the interval is small and there are multiple scheduled tasks, polling can use a large portion of system resources. New timers set to expire sooner than this interval might not run until the interval ends. If this value is too large, a potentially large number of timer events might be loaded into memory because all the timer events occurring in the next poll interval are loaded each time.

The number of threads used to run concurrent EJB Timer tasks. Setting the number of timer threads to zero disables the EJB timer service.

Specifies the JNDI name of a custom Scheduler instance to use for managing and persisting EJB Timers. This field is only used when you select Use Custom Scheduler Instance. Internal EJB timer service scheduler instance configuration information is not applied to the specified scheduler instance.

Specifies the maximum number of times that a failing timeout might be retried. If a timeout is successful upon retry, the server stops attempting to run it. If a retry fails, the server continues to attempt retries until the timeout succeeds, or the timeout limit is reached. Once the retry limit is reached, the server does not attempt to run the timeout, even if the timeout has not succeeded. 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 that specific number of retries are allowed.

Specifies the interval between retry attempts for a failed timeout. The first retry always occurs immediately, regardless of the interval configured here. All additional retries wait for the interval specified here. A value of 0 indicates that all retries are immediate. A value of 1 or higher indicates that retries must wait for that specific number of seconds.

Specifies that non-persistent timers share a thread pool with persistent timers. If persistent timers are using the default internal scheduler instance, the shared thread pool is configured using the configuration settings that are specified in the Persistent EJB timer configuration section. If the persistent timers are using a custom defined scheduler, the thread pool configuration was specified as part of the configuration for that custom scheduler.

Specifies that non-persistent timers do not share a thread pool with persistent timers. Rather, a unique thread pool is created for non-persistent timers only.

Specifies the number of threads available in the unique thread pool that is used for non-persistent timers. This configuration option is only available when non-persistent timers are not sharing a thread pool with persistent timers. This configuration option is different from the Number of timer threads configuration option in the Persistent EJB timers configuration section because that option applies only to persistent timers using the default internal scheduler instance.