It's best to protect against runtime exceptions from your application code being thrown back to the container from the timer method. They are treated as system exceptions. If it's something that's a normal condition in your code and you don't want it to impact the timer, catch it so you'll keep getting the timer callbacks.
Here's the relevant text from the timer chapter of the EJB 3.1 specificaiton :
By default, each Schedule annotation corresponds to a single persistent timer, regardless of the number of JVMs across which the container is distributed.
18.2.3 Non-persistent Timers
A non-persistent timer is a timer whose lifetime is tied to the JVM in which it is created. A non-persistent timer is considered cancelled in the event of application shutdown, container crash, or a failure/shutdown of the JVM on which the timer was started.
Non-persistent timers are not supported for EJB 2.x Entity Beans.
Non-persistent timers can be created programmatically or automatically (using @Schedule or the deployment descriptor). For automatic non-persistent timers, the container creates a new non-persistent timer during application initialization for each JVM across which the container is distributed.
Automatic non-persistent timers can be specified by setting the persistent attribute of the @Schedule annotation to false.
[Message sent by forum member 'ksak']
http://forums.java.net/jive/thread.jspa?messageID=397202