users@glassfish.java.net

Re: Clustered Timer Service Behavior

From: <glassfish_at_javadesktop.org>
Date: Fri, 12 Dec 2008 15:04:34 PST

I'm guessing (I don't know) that what will happen is that when the ServletContextListeners fire, you actually have a race condition.

1 of 2 things will happen.

1, each instance will think it "owns" the timer and execute the job (i.e. if you have 3 servers, it runs 3 times -- this would be bad).

2, when instance A creates the timer, if the timer already exists, that existing timer is "stomped on" and the new timer takes precedence. So, likely, if Instance A creates the timer, then Instance B creates the same timer, B tells A "I'm taking over timer X", and thus B "owns" it.

Mind, this all depends on how it's working.

What I REALLY think happens is that nobody "owns" the timer, rather the timer notes the instance that started the timer in the DB.

Then at regular intervals, the timer service "polls" the timer DB for timers that it owns.When a system fails, the cluster management finds any timers associated with the fail instance, and simply changes the owner to some other system in the cluster. Thus, when that system says "Give me timers I own", suddenly a new timer shows up.

So, if you have 3 instances creating the same timer "at the same time", you really have 3 processes updating the timer db all at the "same time", and thus one will "win" just by being the last one to create the timer.

So, whoever is last in line get caught with the bag and runs the timer.
[Message sent by forum member 'whartung' (whartung)]

http://forums.java.net/jive/thread.jspa?messageID=321518