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 two possibilities.
In a single server environment, it is clear
which server instance should invoke the specified timeout method on
a given bean. In a multi-server clustered environment there are two
possibilities.
- Separate timer service database per server process or cluster
member. This is the default configuration. Only the server instance
or cluster member that created the Timer can access the Timer and
run the timeout method of the bean. If the server instance is unavailable,
the Timer does not run at the specified time, and does not run until
the server is restarted. Also, if an enterprise bean calls the getTimers() method,
only those timers created on the server instance are found. This can
cause unexpected behavior if the enterprise bean attempts to cancel
all timers associated with it; for example, when the enterprise bean
is removed. This configuration is NOT recommended for production level
systems.
- Shared or common timer service database for the cluster. Timers
can be created and accessed on any server process or cluster member.
Timers created in one server process are found by the getTimers() method
on other server processes in the cluster. When an entity bean is removed,
all timers, no matter where created, are canceled. However, all timers
are executed on a single server in the cluster, that is, the timeout
method of the bean is run for all timers on a single server. Which
server executes the timers varies depending on which server process
obtains a lock on the common database tables. If the server executing
timers becomes unavailable, then another server or cluster member
takes over and begins executing all timers at their scheduled time.
This is the recommended configuration for all production level systems.
-
Avoid trouble: When using the EJB Timer service in
an application using multi-threaded database access, application flow
can introduce deadlock problems.
gotcha
To avoid this, use the wsPessimisticUpdate access intent. This access intent
causes the finder method in your application to run a select for
update statement instead of a generic select. This in turn prevents
the lock escalation deadlock when multiple threads try to escalate
their locks to perform an update.
See the developing enterprise beans for the
timer service information to learn how to configure the data source
(database) to be used for each server process timer service.
Note: 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.