Network Deployment (Distributed operating systems), v8.0 > Reference > Sets
EJB timer service settings
Use this page to configure and manage the EJB timer service for a specific EJB container. From the console...
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 your persistent timer tasks. They are persisted to a Cloudscape 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. 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. We must evaluate the number of timers and their expiration frequencies to establish the number of threads.
Data source JNDI name
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
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
Configure a timer service for network deployment
Configure the timer service using scripting
Configure a timer service