Thanks for the reply, Kris. I figured it might be something like that, but was thrown because one of the test cases in PersistentStatefulSessionTest (testPersistenceWorkItems3) does check for process state COMPLETE.
I worked around the issue by adding a ProcessEventListener that implements the afterProcessComplete() method. Since my action upon process completion is to send a JMS message to the person who started the process, using an event listener is actually a little bit cleaner than checking process status after every session state change. Regards, Dan Nathanson On Tue, Mar 8, 2011 at 5:19 PM, Kris Verlaenen < [email protected]> wrote: > Dan, > > Once you start using persistence, you should know that the process > instance you are retrieving is no longer the internal process instance > but a version of the process instance at the moment you requested it. > This process instance however is disconnected, meaning that it will not > automatically update when the internal process instance changes. The > main reason is that, when using persistence, process instances can be > removed and reloaded from database at any time, so you basically get a > copy. > > If you register a listener that listens for process instance completion > right before inserting the list in testPersistenceState(), you will > notice that this process instance gets completed and that the process > instance state of the internal process instance is set to completed. > The copy you still have from before still is in active state though. > Since process instances that are completed are also removed from > persistence as no longer necessary, you can't get the process instance > in state completed. That's why we test whether a process instance is > completed by checking it is null when we try to retrieve it. Another > option would be to use a history logger of course. > > Kris > > Dan Nathanson wrote: > > More info... > > > > This behavior is reproducible in the Drools JPA test cases. > > > > In > > > org.drools.persistence.session.PersistentStatefulSessionTest.testPersistenceState() > > and testPersistenceRuleSet(), if you add a breakpoint before loading > > the processInstance the last time (when it is null because the process > > has "completed"), you can see that processInstance.getState() returns > > 1 (ACTIVE) instead of 2 (COMPLETE). I added the ConsoleLogger to the > > ksession and can see the "AFTER RULEFLOW COMPLETED" log message. > > > > In the other test cases, the state is correctly set to 2 after the > > process completes. > > > > On Mon, Mar 7, 2011 at 11:21 AM, Dan Nathanson <[email protected] > > <mailto:[email protected]>> wrote: > > > > Hi, > > > > I'm seeing some odd behavior in Drools Flow 5.1.1. When using JPA > > and creating a StatefulKnowledgeSession using > > JPAKnowledgeService.newStatefulKnowledgeSession(), processes look > > like they run to completion, but calling > > RuleFlowProcessInstance.getState() on process instances created > > froim this knowledge session returns 1 (STATE_ACTIVE). Calling > > getActiveNodeIds() throws a NullPointerException. > > > > If I get a StatefulKnowledgeSession without JPA by calling > > KnowledgeBase.newStatefulKnowledgeSession(), getState() returns 2 > > (STATE_COMPLETED). > > > > I added > > KnowledgeRuntimeLoggerFactory.newConsoleLogger(knowledgeSession) > > and can see in both cases that the process is complete. > > > > Has this been seen before? Is it a known bug? Am I doing > > something wrong? > > > > Regards, > > > > Dan Nathanson > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > rules-users mailing list > > [email protected] > > https://lists.jboss.org/mailman/listinfo/rules-users > > > > _______________________________________________ > rules-users mailing list > [email protected] > https://lists.jboss.org/mailman/listinfo/rules-users >
_______________________________________________ rules-users mailing list [email protected] https://lists.jboss.org/mailman/listinfo/rules-users
