Use this page to configure and manage the Enterprise JavaBeans (EJB) timer service for a specific EJB container.
To view this administrative console page, click
.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.
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.
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.
You 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. You must evaluate the number of timers and their expiration frequencies to establish the number of threads.
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.
Information | Value |
---|---|
Data type | String |
Default | jdbc/DefaultEJBTimerDataSource |
Specifies an authentication alias to a user name and password used to access the data source.
Information | Value |
---|---|
Data type | String |
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_ |
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.
Information | Value |
---|---|
Data type | Integer |
Units | seconds |
Default | 300 |
Range | 3 to 1800 |
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 |
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 |
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 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 |
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.
Information | Value |
---|---|
Data type | Integer |
Default | 300 seconds |
Range | 0 or greater |
Specifies the 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 |