Well, I'm going to reply anyway.
It DOES make sense, because EJB timers are specific to the APPLICATION, not to the CONTAINER.
All of those other resources that your app relies upon are shareable among all of the applications within the container. EJB Timers are not. EJB Timers are tick down timers tied to a specific Session Bean. When the Session Bean goes away, there's nothing to tie the timer too. Now, certainly, the container can just sit there and silently skip or spam your logs about timers missing session beans. But, really, since the timer is an application artifact, it really should be cleared when the application is undeployed.
Now, is this a pain point? It certainly can be. I think that the timers should be more accessible, from an operations point of view, than they are now.
At the moment, the solution is simple, but lightly hackish. Since the EJB tier doesn't have any real accessible life cycle, you need to bundle a WAR with your EJBs, and that WAR at a minimum will contain a Servlet that loads on start up, and in its init() method, it calls the App tier to reconfigure the timers (typically a method in the timer bean itself). Make sure you don't just insert the timer twice, need to check that it exists first, as your method will fire not just on deployment, but anytime the container starts up. (See the TimerService.getCurrentTimers() method to view the state of the timers in the system, and put something relevant in the Timer.info property to identify your timers.)
Our app can have any number of arbitrarily configured jobs, and we store them in the DB. On start up, we read that table and recreate the timers so they fire properly.
As nice as it would be to just "fire and forget" the timer jobs, it brings up all sorts of issues of how to handle restarts and downtime, etc.
For simple, regular jobs, the Timer is a fine service. As the demands grow, it turns in to a really base asynchronous execution mechanism that needs to be augmented with application code. They could pump up the features some, but it's really one of those services that kind of either works for you or it doesn't, no matter how many features the pour in to it. Some folks want it for "cron", others want it for just wrong background tasks (I use it for both).
As painful as maintaining timers may seem, I think there's a hidden benefit to having your application having complete control over the jobs there.
Anyway, do file an RFE for what you would like to see (the more detailed the better), maybe something can be done in the spec and if not, perhaps in v3.
[Message sent by forum member 'whartung' (whartung)]
http://forums.java.net/jive/thread.jspa?messageID=297896