[rules-users] Process instance status not completing when using JPA.

[Dan Nathanson]

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