EJB timer service settings

Use this page to configure and manage the EJB timer service for a specific EJB container. To view this console page, click Servers > Server types > WebSphere application servers > server name > EJB Container Settings > EJB timer service settings.

Both persistent and non-persistent timers can exist simultaneously, and the persistent and non-persistent configurations are not mutually exclusive. Your application might use both persistent and non-persistent timers.

Use persistent timers when the timer must persist through server shutdowns and restarts. Otherwise, use non-persistent timers when a server shutdown must cancel the timer.

When a persistent timer does not fire because the server is unavailable, then the missed attempt is recovered when the server restarts. When a non-persistent timer does not fire because the server is unavailable, the missed attempt is not recovered, because the server shutdown cancels the non-persistent timer.

Persistent EJB timer configuration

Use internal EJB timer service scheduler instance

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 functionality, and provides limited configuration settings for an EJB timer service.

We can specify to use the internal scheduler instance to manage the 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.

Use custom scheduler instance

We 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. We 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.

We might want to define a custom scheduler instance to isolate threads used by the scheduler service from those threads used by the EJB timer service. EJB timer service threads from a custom scheduler instance might be shared for use with non-persistent timers, or you might configure a separate thread pool for non-persistent timers. Even with a thread pool dedicated to EJB timers, timer expirations might fall behind if there are not enough available threads. We must evaluate the number of timers and their expiration frequencies to establish the number of threads.

Data source JNDI name

Specifies the 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.

Information	Value
Data type	String
Default	jdbc/DefaultEJBTimerDataSource

Data source alias

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

Information	Value
Data type	String

Table prefix

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 could be removed.

Information	Value
Data type	String
Default	EJBTIMER_

Poll interval

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.

Information	Value
Data type	Integer
Units	seconds
Default	300
Range	3 to 1800

Number of timer threads

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

Information	Value
Data type	Integer
Default	1
Range	0 to 500

Scheduler JNDI name

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.

Information	Value
Data type	String

Non-persistent EJB timer configuration

Maximum number of retries

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 execute 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.

Information	Value
Data type	Integer
Default	-1
Range	-1 or greater

Time interval between retries

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.

Information	Value
Data type	Integer
Default	300 seconds
Range	0 or greater

Share thread pool configured for persistent timers

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

Create a separate thread pool for non-persistent timers

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.

Number of timer threads

Number of threads available in the unique thread pool 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.

Information	Value
Data type	Integer
Default	1
Range	0 to 500

Related tasks

Configure a timer service for network deployment

Configure the timer service

Configure a timer service