Question

I have a method annotated with @Schedule that is called by the container once in a while.

@Schedule(second = "*/5", minute = "*", hour = "*", persistent = false)
public void myTimerMethod() throws Exception {
    ...
}

Problem is on certain conditions i want to this method to throw an exception to cause the ongoing transaction to rollback. But if I do this more than two times the timer will be expunged and not called any more!

INFO: EJB5119:Expunging timer ['68@@1359143163781@@server@@domain1' 'TimedObject = MyBean' 'Application = My-War' 'BEING_DELIVERED' 'PERIODIC' 'Container ID = 89072805830524936' 'Fri Jan 25 21:49:30 CET 2013' '0' '*/5 # * # * # * # * # * # * # null # null # null # true # myTimerMethod # 0' ] after [2] failed deliveries

I know i can configure timer rescheduling in domain.xml using

<domains>
    ...
    <configs>
        <config>
            ...
            <ejb-container session-store="${com.sun.aas.instanceRoot}/session-store">
               <ejb-timer-service>
                     <property name="reschedule-failed-timer" value="true"></property>
                </ejb-timer-service>
            </ejb-container>
            ...
        </config>
    </configs>
    ...
</domains>

But my question is, can I have this setting configured when i deploy my application?

Can’t find it in:

glassfish-resources.xml
glassfish-ejb-jar.xml
glassfish-web.xml

Is there some way to do it programmatically maybe?

(My rationale behind behind putting server-configuration like this in config files rather than configuring the server is so my app should be possible to install directly on a fresh installation of glassfish)

Answer 1

I’d use a different approach.

Instead of throwing an exception directly from the scheduled method, try to introduce a level of indirection as in:

...
@Inject RealWorkHere realImplementation;

@Schedule(second = "*/5", minute = "*", hour = "*", persistent = false)
public void myTimerMethod(){
  try{
     realImplementation.myTimerMethodImpl()
  }catch (Exception x){
   // hopefully log it somewhere
  }
}
...

where RealWorkHere is the bean with the actual implementation as in:

@Stateless
public class RealWorkHere{
   @TransactionAttribute(REQUIRES_NEW)
   public void myTimerMethod() throws Exception {

   }
}

This comes with the benefit of:

• Not throwing an exception in a container-initated transaction (thus avoiding the expunging)
• Better logging of the Exception
• Clear demarcation of the ‘real’ business transaction

See also

• ejb-spec #111: Please clearify the behaviour of an container if an application exception is thrown during the execution of a timer callback method