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#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...