Are you using the hot deploy? I get the same thing happening with my Quartz events. The hot deploy effectively doesn't deregister the old event and also adds a new event.
Do you find that doing a full undeploy/reploy makes the event fire only once?
No, I'm not using hot deploy. Anyway, I've the problem both with Quartz and TimerService.
Sorry, you had right. The calls were due to EJBTimer timeout's that was saved by JBoss during previous deployment. Is it a bug of JBoss?
No, this is a feature of EJB3 timer - read a book or the spec!
Quartz or the Java SE timer are non-persistent by default.
I know that EJB3 Timer is persistent but is-it normal that JBoss add new timeout in its database each times the application is deployed?
I haven't the problem with Glassfish.
Is possible to use @Asynchronous to create a non-persistent timer? I know it is an RTFM, but I can't find the right M to RTF. :-( All I ever see is "EJB3 Timers persist by default", but nothing on how to override that default behavior.
vfaid, ask in the EJB3 forum
JakeC - not with the EJB3 timer, but it is with the Quartz timer.