3:38 a.m.
hi,
i've a very simple process with only 4 work items that run async. For steps
WI1 & WI2 i complete each step but when the process reaches WI3 step i
manually kill the whole process and then load it from a database
i.e.
ksession.loadStatefullSess..
Now after i complete WI3 step i can see that the last step i.e. WI4 gets
executed and marked as completed but when i'm checking my process status its
status is still ACTIVE instead of COMPLETED ?
ksession = JPAKnowledgeService.loadStatefulKnowledgeSession(
mySessionId, getKnowledgeBase(), null, getEnvironment());
ProcessInstance processInstance = ksession.getProcessInstance(myProcessId);
//after below line i can see that WI3 & WI4 get completed
ksession.getWorkItemManager().completeWorkItem(workItemIdForWI3, null);
//here the process still remains as ACTIVE ie.1
processInstance.getState() == ProcessInstance.STATE_ACTIVE
what i've seen in the tables is that all tables (i.e. processinstanceinfo,
variableinstanceinfo,workiteminfo) excepts sessionInfo gets cleared after
completing WI3. Why despite completing all work items the process remains
ACTIVE when in fact it should be COMPLETED
--
View this message in context:
http://drools.46999.n3.nabble.com/completing-persisted-workItem-doesn-t-c...
Sent from the Drools: User forum mailing list archive at Nabble.com.
7:14 a.m.
New subject: completing persisted workItem (the last in a process) doesn't complete a process
hi,
two updates to the previous post:
1. it looks like the reason why i can't see the process status changed to
COMPLETED is because of something going wrong with JPA and what a session
obtained using its API can see i.e.
my custom work item code looks like below:
public void executeWorkItem(final WorkItem workItem, final WorkItemManager
workItemManager)
Thread t = new Thread(){
@Override
public void run()
{
// here come my custom code
//this is the same knowledgeSession i got during session creation
knowledgeSession.getWorkItemManager().completeWorkItem(workItem.getId(),
action.getResults());
}
};
t.start();
}
so basically i spawn a new tread to have the action executed async. and once
done i mark the workItem as completed. What i've noticed when debuging the
whole code is that completing the workItem [b]does indeed[/b] set the
process status to COMPLETED but somehow this change isn't visible by the
thread the whole process has been kicked off. Another interesting thing is
that if i run the whole process using session obtained as below
ksession = kbase.newStatefulKnowledgeSession (and not by using persistence
api i.e. ksession =
JPAKnowledgeService.newStatefulKnowledgeSession(getKnowledgeBase(), null,
getEnvironment()) ; )
everything works fine
2. i figured out that the sessioninfo isn't cleared because my code doesn't
call ksession.dispose() method
--
View this message in context:
http://drools.46999.n3.nabble.com/completing-persisted-workItem-the-last-...
Sent from the Drools: User forum mailing list archive at Nabble.com.
9:18 a.m.
New subject: completing persisted workItem (the last in a process) doesn't complete a process
for those interested the problem was that i misinterpreted ProcessInstance
object as something that always gets updated whenever underlying process
changes, whereas in fact that's the version of a process obtained at the
specific moment. This is especially true while working with persistence. So
the bottom line is that in order to check process status the best way to do
it is to create ProcessEventListener object and add it to the created
session....
similar thread http://comments.gmane.org/gmane.comp.java.drools.user/24622
--
View this message in context:
http://drools.46999.n3.nabble.com/completing-persisted-workItem-the-last-...
Sent from the Drools: User forum mailing list archive at Nabble.com.
10:50 a.m.
New subject: completing persisted workItem (the last in a process) doesn't complete a process
I ran into this issue also. I was told that the ProcessInstance you
are looking at is just a snapshot of what was loaded from the DB. It
doesn't get updated after being loaded. I wasn't told why this was
the behavior, just that it was expected. Didn't seem intuitive to me.
I was told that the way to check for process completion is to try to
load the process from the DB again and if it is null, then it is
complete. I didn't like that solution so I wrote a
ProcessEventListener to detect process completion because I needed to
send a JMS message.
Regards,
Dan Nathanson
On Tue, Apr 12, 2011 at 7:18 AM, gs76pl <gstasica(a)pacemetrics.com> wrote:
for those interested the problem was that i misinterpreted
ProcessInstance
object as something that always gets updated whenever underlying process
changes, whereas in fact that's the version of a process obtained at the
specific moment. This is especially true while working with persistence. So
the bottom line is that in order to check process status the best way to do
it is to create ProcessEventListener object and add it to the created
session....
similar thread http://comments.gmane.org/gmane.comp.java.drools.user/24622
--
View this message in context:
http://drools.46999.n3.nabble.com/completing-persisted-workItem-the-last-...
Sent from the Drools: User forum mailing list archive at Nabble.com.
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
11:14 a.m.
New subject: completing persisted workItem (the last in a process) doesn't complete a process
A process instance is "disconnected" once the command is completed.
This means that it will represent the state at the end of the command
and won't be updated when the process instance actually changes. You
can however always get the latest snapshot using
ksession.getProcessInstance(id). There are a few reasons for doing this:
* It allows a process instance to be updated from two separate
sessions, since the process instance will be reloaded from database when
it is needed again, so it will take the changes into account that were
introduced by another session.
* When using persistence, you're not supposed to manipulate the process
instance directly (as this will be out of the scope of the transaction
and the engine wouldn't be aware), disconnecting the instance means you
can't, you're supposed to treat it as a data object.
* This also allows remoting where the process instance can be sent to
anywhere else (and here the use of a DTO that represents a snapshot it
common)
Note that this is only when you are using persistence, when using the
core engine directly, you get access to the "live" process instance
directly.
Kris
Dan Nathanson wrote:
I ran into this issue also. I was told that the ProcessInstance you
are looking at is just a snapshot of what was loaded from the DB. It
doesn't get updated after being loaded. I wasn't told why this was
the behavior, just that it was expected. Didn't seem intuitive to me.
I was told that the way to check for process completion is to try to
load the process from the DB again and if it is null, then it is
complete. I didn't like that solution so I wrote a
ProcessEventListener to detect process completion because I needed to
send a JMS message.
Regards,
Dan Nathanson
On Tue, Apr 12, 2011 at 7:18 AM, gs76pl <gstasica(a)pacemetrics.com> wrote:
> for those interested the problem was that i misinterpreted ProcessInstance
> object as something that always gets updated whenever underlying process
> changes, whereas in fact that's the version of a process obtained at the
> specific moment. This is especially true while working with persistence. So
> the bottom line is that in order to check process status the best way to do
> it is to create ProcessEventListener object and add it to the created
> session....
>
> similar thread http://comments.gmane.org/gmane.comp.java.drools.user/24622
>
> --
> View this message in context:
http://drools.46999.n3.nabble.com/completing-persisted-workItem-the-last-...
> Sent from the Drools: User forum mailing list archive at Nabble.com.
> _______________________________________________
> rules-users mailing list
> rules-users(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>
>
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
4777
days inactive
4777
days old
4 comments
3 participants
participants (3)
-
Dan Nathanson -
gs76pl -
Kris Verlaenen