Let me try to help you. I think the timer survives container crash or server shutdown because we have registered with timer service for our enterprise bean to EJB container (using either annotation metadata or deployment descriptor).
So, when the container or server starts up again, it will read our configuration and make the timer service available for our enterprise bean.
Daniel, I got the answer for this from the spec itself.Here is what the spec has to say
Timers are persistent objects. In the event of a container crash, any single-event timers that have expired during the intervening time before container restart must cause the timeout callback method to be invoked upon restart. Any interval timers that have expired during the intervening time must cause the timeout callback method to be invoked at least once upon restart.
If the transaction in which the timer cancellation occurs is rolled back, the container must restore the duration of the timer to the duration it would have had if it had not been cancelled. If the timer would have expired by the time that the transaction failed, the failure of the transaction should result in the expired timer providing an expiration notification after the transaction rolls back.
when you really want something, all the universe always conspires in your favour.<br /> <br />SCJP1.5-77%<br />SCWCD-89%
Well, the operative part of that spec excerpt (i.e., the answer to your question) is just the first sentence: Timers are persistent objects. That means all information necessary to revive them after a crash is being put into permanent storage (e.g. a database). The rest is just the details of their operation.
A magnificient life is loaded with tough challenges. En garde tiny ad:
Free, earth friendly heat - from the CodeRanch trailboss