Yea, the timers do kind of exist in a "no mans" land. On the one hand being applications state (and not just application state, but persistent applications state), but on the other being a container artifact that the container is somewhat responsible for (thus dumping them on undeploy).
I think it would be a fair RFE to make Timers persistent across redeploys as a deployment (or, perhaps, undeployment) option.
As for the scaling issue, that 100,000 is certainly a big number, and I can easily see an implementation being blindsided by such a volume of timers.
On the one hand, the naive implementation would be to simply load all of the timers in memory at start up. For any "reasonable" number (< 1000, say, depending on the size of the getInfo blob), that's not an absurd idea. Frankly, it's not even an absurd assumption.
But when that number goes to 100,000 -- yea, there could be issues.
As an alternative, it could be implemented as a simple query:
SELECT * FROM TIMER WHERE RUNDATE <= <now>
And just run that every minute, queuing up each job. That will scale until the cows come home. Now, if you're firing 1000's of jobs per minute, well, there are other issues involved with that as well.
That works well and good until someone calls "getTimers()". Then, there's, well, ouch. That call is not scalable.
Frankly I think your solution of managing your own timers, giving your volume, is probably best. I would have most likely leveraged the timer service as the runtime engine for such a model (rather than manage my own threads), plus the timers jobs run in the EJB tier, whereas servlet threads don't. Yea, it's kind of a moot point if all your servlet thread does is call a session bean, but, still. I like that the timers are in the EJB tier. Suits my world view better.
[Message sent by forum member 'whartung' (whartung)]
http://forums.java.net/jive/thread.jspa?messageID=298464