Creating a jbpmContext is a lightweight operation, basically it is a wrapper 
for a Hibernate transaction.   ????? I was confused before . now I see.

persistence object ????? I know it is a good idea, I mean the web application 
close the context after the processinstance.close(); so the whole workflow 
instance will close, but not to commit the data after a certain node.

however, there is a problem: after one thread of instance process has ended, 
the other clients will lose the jbpmContext after the client end the context. 
The root cause is that the jbpmContext is existed in a static class.
So I changed the code from static class to a constructor one, which instance a 
new one every time when the web application thread requested. then more 
problems came because every instance of it contains a separate jbpmContext, 
thus a separate jbpmSession, thus a separate Persistence Object(PO).  The 
result turned out that different clients get different result. If one changed 
something, the other swinlane can't see any thing changed. if one want to 
getSession.flush(), he will find that tables were locked by the other 
jbpmContext.

Do jBPM only permit one jbpmContext in a web application ?

If you're thinking that you want to keep the context open across multiple user 
interactions, as Ronald said, that's generally bad web-app practice - it scales 
badly. ?????? ?jbpm doesn't support in the scenario of multiple 
web-application-user interactions? 

View the original post : 
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4047850#4047850

Reply to the post : 
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4047850
_______________________________________________
jboss-user mailing list
[email protected]
https://lists.jboss.org/mailman/listinfo/jboss-user

Reply via email to