[rules-users] Process instance status not completing when using JPA.
Dan Nathanson
dan at ddnconsulting.com
Tue Mar 8 21:17:56 EST 2011
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 <
kris.verlaenen at cs.kuleuven.be> 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 <dan at ddnconsulting.com
> > <mailto:dan at ddnconsulting.com>> 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
> > rules-users at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/rules-users
> >
>
> _______________________________________________
> rules-users mailing list
> rules-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-users/attachments/20110308/46560c60/attachment.html
More information about the rules-users
mailing list