Attached you can find a test case that has the following behaviour: First, there is a process that has two script tasks and one human task that has bounded an interrupting timer. The test case, first configures a persistent environment using Bitronix and H2 ( this has been tested also using JBoss and PostgreSQL ), then a knowledgebase is configured using the previous BPMN process definition, then human task service and persistence are configured along with the defautl human task handler, and an StatefulKnowledgeSession is created. Then there's a loop of 10 cycles of: - Begin transaction - Start the process ( then it executes until the timer waits for 30 days ) - commit or rollback ( if cycle % 2 ) After that, the serialized KnowledgeSession is retrieved from the database using just JDBC, and then is rehydrated using ProtobufMarshaller. Well, what you will be able to see is that rolling back transactions that involved executing a process that had timers inside, made the timers multiplicate in the session. ( You can see this by placing a breakpoint into "ProtobufInputMarshaller [line: 154] - readSession(MarshallerReaderContext, int, ExecutorService, Environment, SessionConfiguration) " and inspecting the contents of the variable _session ). rehydrating the session one can see that were created 46 timers !!. This is really weird, but it is weirder to find that there is some kind of pattern ). If you take a look at what is inside the protocol buffers serialized version of the knowledge session you can find that there's a direct relation between the groups in the focus_stack, which in the example is: focus_stack { group_name: "MAIN" group_name: "MAIN" group_name: "MAIN" group_name: "MAIN" group_name: "MAIN" } and the number of repetitions of each timer ( associated with each process instance ) are multiple of the number of group_names in the agenda. For example if there are 5 items in the focus_stack there will be no more than 2^4 ( 16 ) repetitions of each timer. But all timers are congruent with 2^x-1 where x is the number of group_name in the agenda. In fact, if you leave the timer behind ( just by changing the process ) you will still be able to find that when executed there are 5 !! group_name inside the focus_stack. I've created a bug in Jira JBPM-3831 : https://issues.jboss.org/browse/JBPM-3831 Any insight? Alberto R. Galdo argaldo(a)gmail.com