Configure a timer service
We can configure and manage the EJB timer service for a specific EJB container.
WebSphere Application Server implements the EJB Timer Service. Based on the business needs, we can use persistent timers or non-persistent timers. Persistent timers are helpful if we are creating a timer for a time-based event that requires assurance of timer existence beyond the life cycle of the server to persist through server shutdowns and restarts. Previously started persistent timers automatically start when the server starts, and they require a database instance.
Non-persistent timers do not use a data store and are canceled when the application server is stopped or fails to remain in an active state. Non-persistent timers exist only on the server where the timer is created.
Both persistent and non-persistent timers require a work manager. Persistent timers use the work manager used by the scheduler service. Non-persistent timers use the server default work manager by default, but can be configured to use another work manager using EJB timer scripting. Non-persistent timers do not use the scheduler service.
We can configure and manage the EJB timer service for persistent and non-persistent timers in the administrative console. The configuration for persistent and non-persistent timers is not mutually exclusive. The application might contain both persistent and non-persistent timers.
Tasks
- Click Servers > Application servers > server > EJB Container settings > EJB timer service settings.
- Configure the persistent EJB timer support.
- To use the internal, or pre-configured, scheduler instance, select Use internal EJB timer service scheduler instance. If we choose not to change the default settings, this instance for the scheduler is associated with an Apache Derby database. If we choose to customize the pre-configured instance:
- To change the data source, enter your Data source JNDI name. Use any supported database, such as DB2 or Oracle.
- Enter your chosen Data source alias.
- Enter your chosen Table prefix to have several server processes use the same database, but different tables.
- Enter a Poll interval value in milliseconds.
- If we want more timers to run concurrently, enter a new value for Number of timer threads.
For more details, see information about timer service settings.
- To configure our own scheduler instance instead of using the pre-configured internal one, select Use custom scheduler instance. We might want to use our own instance to:
- Change scheduler service configuration options not available for customization on this panel
- Keep EJB timer tasks in the same database tables as your other tasks
- Have a single scheduler instance handle all the EJB timers in a cluster. This way, an ejbTimer task created on one cluster member can run on a different cluster member.
To use our own instance, we must:
- Configure a scheduler instance through the scheduler service graphical user interface. See the using schedulers documentation for information about how to do this.
- Select your Scheduler JNDI name from the list.
- Configure the non-persistent timer support. Support for non-persistent timers is configured in addition to (not instead of) support for persistent timers.
- Enter your chosen Maximum number of retries.
- Enter your chosen Time interval between retries.
- Select the Share thread pool configured for persistent timers or the Create a separate thread pool for non-persistent timers option. If we choose the Create a separate thread pool for non-persistent timers option, enter your chosen Number of timer threads.
- Optional: Configure data caching for our EJB timers. Caching allows the application server to reuse timer data without having to query the database each time that data is required. See the topic on caching data for a timer service for information on configuring this feature.
- Click Apply.
- Click OK.
Subtopics
- Configure a timer service for network deployment
We can configure the EJB timer service for timers that can persist through application server shutdowns and restarts.- Caching data for a timer service
To optimize database access and SQL calls for an EJB timer service, we can enable the application server to cache data for that timer. Caching allows the application server to reuse timer data without having to query the database each time that data is required.- Configure the timer service using scripting
Use wsadmin scripting to configure the EJB timer service.- EJB timer service settings
Configure and manage the EJB timer service for a specific EJB container.- Configure a timer service for network deployment
We can configure the EJB timer service for timers that can persist through application server shutdowns and restarts.- Caching data for a timer service
To optimize database access and SQL calls for an EJB timer service, we can enable the application server to cache data for that timer. Caching allows the application server to reuse timer data without having to query the database each time that data is required.- Configure the timer service using scripting
Use wsadmin scripting to configure the EJB timer service.- EJB timer service settings
Configure and manage the EJB timer service for a specific EJB container.
Use schedulers