There are two concepts here: 1) WorkItem -> Persist the state of the activity 2) WorkItemHandlers -> Never Persisted
Are you re-registering the WorkItemHandlers at rehydratation? WorkItemHandlers are part of the runtime status and don't get persisted. Cheers On Fri, Jun 22, 2012 at 9:39 AM, Alberto R. Galdo <arga...@gmail.com> wrote: > No, I'm not registering pending workitems at rehydration. That's why I'm > using Drools & JBPM persistence ;-). I don't want to write my own state > persistence, as I am a mere user of JBPM & Drools services. > > >> "They are never persisted" > > This several methods in org.drools.persitence.jpa.JPAPersistenceContext > seem to say just the opposite: > > public void persist(WorkItemInfo workItemInfo) > public void remove(WorkItemInfo workItemInfo) > public WorkItemInfo merge(WorkItemInfo workItemInfo) > > The fact that lots of workitems get created, persisted, merged and finally > removed during the life of the process doesn't hide the fact that they're > in fact, .... well, persisted. > > If you take a look at the changes in the database whenever a human task is > involved in a BPMN process that is executed inside a Drools & JBPM JPA > persisted environment you will realize that indeed the human task are > *persisted* and like so, rehydrated when loading the session in Drools. In > fact, those human task related workitems are never removed from the > database, but that's another bug ... :( > > Any insight? > > Alberto R. Galdo > arga...@gmail.com > > > > On Fri, Jun 22, 2012 at 2:15 PM, Mauricio Salatino <sala...@gmail.com>wrote: > >> "We are unable to complete a human task after rehydrating a Drools >> knowledge session because in some circunstances the generated Drools' >> workitems don't get persisted in the database after the completion of a >> previous task" >> >> They are never persisted, they are runtime information that you must >> re-register after rehydrating the session. Are you doing that? >> Cheers >> >> On Fri, Jun 22, 2012 at 7:34 AM, Alberto R. Galdo <arga...@gmail.com>wrote: >> >>> Hi, >>> >>> We have a fairly large BPMN process running inside a JPA persisted >>> StatefulKnowledgeSession using Drools 5.4 & JBPM 5.3. Our process involves >>> timers, automated tasks, human tasks .... most of them are long-running >>> processes, so a fault-tolerant scenario is a must. >>> >>> We've found what seems to be a weird, weird bug in JBPM-Drools >>> regarding the execution of BPMN processes. This is by best to summarize the >>> problem: >>> >>> "We are unable to complete a human task after rehydrating a Drools >>> knowledge session because in some circunstances the generated Drools' >>> workitems don't get persisted in the database after the completion of a >>> previous task" >>> >>> So, as the workitem is not in the database, when a human task client >>> completes a task that is related to that non-existent workitem, the process >>> doesn't get restarted. And the process fails. >>> >>> ¿Why does this happens? Lets see: >>> >>> When the processs is executed, different workitems get created, >>> updated and eventually deleted during the execution of a process up until a >>> human task is created ( in our process ). When living in a persistet >>> knowledge session, the transaction that is associated to Drools' thread is >>> commited right after the human task is created in the human task server ... >>> as it is a "safe point". Nothing here. Everithing is consistent, if you >>> look at the database you will see your session instance, your process >>> instance, and the final human task workitem as it is the only workitem >>> survivor after the execution ( whatever hadler-managed automated task that >>> were executed before the human task are deleted and the human task workitem >>> needs to survive as it's completion depends on asyncronous client >>> interaction ). >>> >>> Now, if you connect to the human task server and complete that >>> human task, a message is sent to the Drools session to update the state of >>> the work item. The workitem gets updated, the process get restarted and the >>> flow continues ... maybe generating a new human task ( which is our case ). >>> At this very moment, if you take a look at the database, there are no >>> automated-handled-task workitems ( as expected ) but there isn't any human >>> task related work item, even worse, the task at the human task server is >>> created, persisted and has a reference to the non-existant workitem. >>> >>> Days of debugging led us to what we think is the source of the >>> problem: >>> >>> We found that the execution of the process after completing a task >>> is being executed in the same thread as the one that receives the mina >>> message that the human task server sends whenever a task is completed. This >>> thread is not the same thread that executes the knowledgesession ( where >>> the reteoo lives ) and so it doesn't have a transaction. By the way, we >>> found that for workitem persistence the JPAWorkitemManager never joins an >>> active transaction. :( >>> >>> That's why invoking the persistence of a workitem as a consequence >>> of restarting the execution of a process inside the thread that receives >>> the mina messages makes the database inconsistent, and so invalidating all >>> means to make JBPM fault tolerant by making Drools session persistent. >>> >>> We found a way to circunvent this problem, making all our human task >>> nodes be followed by a event timer. That way, when the timer gets completed >>> we force the execution of the process to live in the same thread that the >>> reteoo session lives where a transaction is available and things get back >>> to normal. But this is really dirty and wrong. >>> >>> Any thoughts? >>> >>> We are really eager to be wrong whith this. :'( >>> >>> Greets, >>> >>> >>> >>> Alberto R. Galdo >>> arga...@gmail.com >>> >>> >>> >>> _______________________________________________ >>> rules-users mailing list >>> rules-users@lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/rules-users >>> >>> >> >> >> -- >> - MyJourney @ http://salaboy.wordpress.com >> - Co-Founder @ http://www.jugargentina.org >> - Co-Founder @ http://www.jbug.com.ar >> >> - Salatino "Salaboy" Mauricio - >> >> >> _______________________________________________ >> rules-users mailing list >> rules-users@lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/rules-users >> >> > > _______________________________________________ > rules-users mailing list > rules-users@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/rules-users > > -- - MyJourney @ http://salaboy.wordpress.com - Co-Founder @ http://www.jugargentina.org - Co-Founder @ http://www.jbug.com.ar - Salatino "Salaboy" Mauricio -
_______________________________________________ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users