Hi Felix,
What is the nature of the error? It is a transaction rollback caused by the database or is the timer method throwing a runtime exception back to the container?
The deletion you're seeing is actually the spec-defined behavior. By default each @Schedule is equivalent to the creation of a single persistent timer. Once created by the container, it has the same semantics as programmatically created timers, which means that after enough redelivery attempts due to rollback or exception the timer will be removed. Since it has persistent semantics tied to the deployment of the application, it won't be automatically recreated upon server restart or any other event. One workaround is to increase the number of redelivery attempts by the container. You can do this via the admin console.
Another alternative is to switch to a non-persistent timer. Non-persistent timer lifetimes are tied to the JVM, not a persistent store. In the case of @Schedule(persistent=false), each time the server is restarted a new timer will be created.
[Message sent by forum member 'ksak']
http://forums.java.net/jive/thread.jspa?messageID=397151