TimerImpl sets ACTIVE state after it's scheduled the timer task which means that you can have a race
condition leading to something like this:

2009-04-28 18:55:03,370 45084 DEBUG [org.jboss.ejb.txtimer.TimerImpl] (ScannerThread setTimerState: created
2009-04-28 18:55:03,372 45086 DEBUG [org.jboss.ejb.txtimer.TimerImpl] (EJB-Timer-2[target=jboss.j2ee:service=EJB3,jar=acme-ejb3.jar,name=ProblematicTimerManagerProxyBean] run: [id=2,target=[target=jboss.j2ee:service=EJB3,jar=acme-ejb3.jar,name=ProblematicTimerManagerProxyBean],remaining=-438372,periode=0,created]
2009-04-28 18:55:03,372 45086 DEBUG [org.jboss.ejb.txtimer.TimerImpl] (EJB-Timer-2[target=jboss.j2ee:service=EJB3,jar=acme-ejb3.jar,name=ProblematicTimerManagerProxyBean] setTimerState: in_timeout
2009-04-28 18:55:03,372 45086 DEBUG [org.jboss.ejb.txtimer.TimerImpl] (ScannerThread setTimerState: active

Sometimes, the timer can kick off even before it's timer state has been set to active, which means that active state will be set after in_timeout.
What's the effect of this? After the timer has executed, this means that the finally clause in TimerTaskImpl.run() won't be executed and hence,
the timer won't be deleted from the database. This leads to multiple timer executions.

Please find attached a thread dump where you can see EJB-Timer-1 being executed correctly, including removal from database, but EJB-Timer-2 is not.