Hi, thanks for the great answers guys. I really appreciate that.
Re: always been like this - other app servers, eg, JBoss have a setting to prevent timer removal. They occasionally refer to the automatic removal of timers as "the old way"...
Re: timers belong to app, not container. Yes indeed - that is **precisely** my point. And yes, indeed, timers are not like other shared resources, they are much more like app data resources. Which is why they should be under control of the app, not the container. And just like my app can be configured not to drop data tables, same should go for timers.
So let me throw out a strawman RFE - allow the timers to be placed under a persistence unit. Maybe move/add some timer apis to the entity manager or sim. These timers would have a PU based life cycle. Question - if this were done, would there be any use for the current timers? I'm not sure, perhaps they could coexist.
I agree that leaving them on undeploy is a problem given the current setup. I believe the design/spec has problems here.
I thought of all those things you mentioned, in the end I simply wrote my own timers and stuck them in my own db. I'm using foreign keys instead of handles, which gives me better integrity. (at the loss of generality).
I'm using a servlet context to start (and end) my timer thread. I have control over transaction batching, timer semantics (like repeat every month, etc), granularity. I did this because I could have 100,000s of timers and I cannot trust the container implementation to scale, and I don't want to be restoring them on redeploy. So, I'm happy, but also sad that one of the main reasons I chose EJB technology turned out to be moot.
~Mark
[Message sent by forum member 'mrawl' (mrawl)]
http://forums.java.net/jive/thread.jspa?messageID=297952