+

Search Tips   |   Advanced Search

Clustered environment considerations for timer service

In a single server environment, it is clear which server instance should invoke the timeout method of the bean on a given bean. In a multi-server clustered environment there are other considerations governing the behavior.

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 survive 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 they are created. In a clustered environment, if your EJB application automatically creates a non-persistent timer and this application is mirrored on multiple servers, each server has its own non-persistent timer that runs within that server environment. A programmatically created non-persistent timer only runs in the cluster member that it was created in.

When configuring a persistent timer in a multi-server clustered server environment, consider the following possibilities for the server instance to invoke the timeout method on a given bean:

See the information on using the EJB timer service for enterprise beans to learn how to configure the data source (database) to be used for each server process timer service.

Once the data source for the timer service is changed to point to a different database, the server process automatically attempts to create the required tables in that database on the next server start. If the user ID associated with the start of the server process is not authorized to create database tables in the configured timer service database, then the tables must be created manually.

When we use the proxy server in the product, do not define a scheduler at the cell level if that scheduler is configured as the one to use for the EJB timer service. Doing so prevents persistent timers from running. This can happen if the proxy server gets the scheduler lease. Since no applications run in the proxy server, there is no application code to handle the timer events sent by the scheduler..

When configuring an EJB Timer/Scheduler, remember that the default scheduler uses the simple file-based Apache Derby database by default so that we can quickly get a functioning environment up and running. DO NOT use the Derby database for production use. Moreover, the default Derby database does not support a clustered job scheduler, nor a clustered batch container.

  • Create timers using the EJB timer service for enterprise beans
  • Configure a timer service