the current impl of the timer executor will rollback the transaction if an exception comes out of the timer execution.
does that answer your question ?
Thanks for the reply. I am using 3.1 and in my design, I have wrapped JBpm in session beans and as I have experienced, I need to add a setRollbackOnly to make effective rollbacks to the process instance. I am assuming also that the close statement in the context will flush and commit the data ( Is this assumption correct?)
Anyway, in my design for the timer, the scheduler thread is still in the servlet. I had to copy and paste your executeTimers code into a session bean which is called by the servlet. I have seen in the code that there is no setRollbackOnly only a close statement. What is the correct behavior in this scenario: I have 20 timer tasks in a scheduled run. The first 10 timers have already executed correctly. If I abort the process, which means it was not able to close the context, am I guaranteed that the 10 timers will have already committed or will it rollback?
P.S. This arose because as I was testing a state having two timers, wherein 1 timer cancelled the other timer, the other timer was not deleted in the database. To correct the situation, I had to do an extra save processInstance in the executeTimers method. Simply calling saveTimer seems to not save the other cancelled or deleted timers.