Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>The short answer is that I don't think this is specified.</p> <p>The long answer is that I was sure this was specified until I looked through the EJB 3.2 spec and the javax.ejb API doc, and I couldn't find anything that said definitively. The spec is clear that if a single timeout fails that it must retry at least once (which would create a weird scenario where an "old" timeout is retrying after a "new" timeout has succeeded) and that if the container/application is down when a timer should have fired that it needs to fire at least one "catch up", but I couldn't find anything that talked about overlapping timeout methods.</p> <p>I don't know what JBoss does, but for others that find this answer, I do know that WebSphere Application Server implements timeout callbacks for a single Timer in a "serial" fashion. That is, only one outstanding timeout can be active for a single Timer, and a subsequent timeout callback will not occur if a previous one is still executing or retrying. After the delayed/retried timeout completes, the server will fire "catch up" timeouts immediately. This behavior could be stated more explicitly, but the <a href="http://pic.dhe.ibm.com/infocenter/wasinfo/v8r5/topic/com.ibm.websphere.nd.multiplatform.doc/ae/tejb_timerserviceejb_enh.html" rel="nofollow">Creating timers using the EJB timer service for enterprise beans</a> topic in the InfoCenter alludes to this behavior when discussing retries:</p> <blockquote> <p>A missed execution is a timeout that must have been attempted, but was not, because the server was unavailable or busy retrying a previously failed timeout.</p> </blockquote>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload