Problem two timers in row - second timer not created

[groezinger]

Hi,

I have the following situation (shown in the process definition below):
Expiration of the first timer triggers a transition to a state which creates a second timer.

However, when executing this process, the state timed_state_2 is entered, but the second timer never expires.

Is this a bug or do I miss something?

Mike

<?xml version="1.0" encoding="UTF-8"?>
<process-definition name="timers5">

 <start-state name="start">
 <transition name="ok" to="timed_state_1"></transition>
 </start-state>

 <state name="timed_state_1">
 <timer name='deadline_1' duedate='10 seconds' transition='timeout' />
 <transition name="timeout" to="timed_state_2"></transition>
 </state>

 <state name="timed_state_2">
 <timer name='deadline_2' duedate='10 seconds' transition='timeout' />
 <transition name="timeout" to="end"></transition>
 </state>

 <end-state name="end">
 </end-state>

</process-definition>

[patka]

"groezinger" wrote:
I have the following situation (shown in the process definition below):
Expiration of the first timer triggers a transition to a state which creates a second timer.

However, when executing this process, the state timed_state_2 is entered, but the second timer never expires.

Is this a bug or do I miss something?

I've experienced the same thing. IMO this is a bug. My work-around to this problem is: custom SchedulerListener which saves all scheduled timers for a process instance associated with a given timer.

A code sample (such listener must be registered at SchedulerThread instance):

public class SaveTimersSchedListener implements SchedulerListener {
 public void timerExecuted(Date date, Timer timer) {
 ProcessInstance pi = timer.getToken().getProcessInstance();
 SchedulerSession schedulerSession = JbpmSession.getCurrentJbpmSession().getSchedulerSession();
 for (Iterator i = pi.getSchedulerInstance().getScheduledTimers().iterator(); i.hasNext(); ) {
 Timer schedTimer = (Timer) i.next();
 schedulerSession.saveTimer(schedTimer);
 }
 }
}

patka

[patka]

"patka" wrote:
I've experienced the same thing. IMO this is a bug.

And one more note on this topic: the problem arises because the timers are not automatically persisted. In the normal process flow the scheduled timers are persisted during saveProcessInstance (look at the saveProcessInstance definition you will see explicit invocation to saveTimers; the same is for process logs). However during processing of timers by scheduler, saveProcessInstance is not called thus no timers persisted. So my solution with listener is a work-around to this problem.

patka