> Either way, I assume a timer
> expiration only occurs once across the cluster so we
> don't have the same timer callback invoked more than
> once across the cluster, right?
Yes, that's the key. The basic tenet of all the clustered EJB behavior is that the application semantics should stay the same independent of whether the application is running on a
single instance or in a cluster. ( Of course in the cluster case hopefully with better throughput/performance). Another good example is MDBs. If you send a message to
a queue associated with an MDB deployed to a cluster, you want it processed once, not N times.
For timers, each will result in the same number of timeout callbacks whether it was created in a
stand-alone server instance or within a cluster. In the same way that the container can
choose any stateless session bean instance to service a stateless session bean invocation,
the container can pick any server instance in the cluster to make the timeout callback.
The way our clustered implementation works is that each server instance starts out "owning"
all the timers that are created within its JVM. These are stored in the single shared
database. The owner is responsible for delivering the timeout callbacks. In the event of a server failure the timers are migrated to one or more healthy server instances in the cluster.
This happens in concert with any transaction failover activities.
>
> I'd appreciate any feedback or pointers to
> documentation explaining how the EJB Timer Service
> works in a Glassfish cluster. Thanks in advance!
[Message sent by forum member 'ksak' (ksak)]
http://forums.java.net/jive/thread.jspa?messageID=321264