how to save processinstance

[cron1]

Question: I can't save the processinstance use the method of save

Scenarios: A web application.
There is a static helper class to createJbpmContext, and the workflow will begin after the first user logon, so there is always existing a jbpmContext in the helper class. we driver the workflow instance to go on, never call jbpmContext.close(), only call jbpmContext.save(processInstance).
throung the workflow goes on well, but no data were saved in the database.
I do know jbpmContext.close() can cause the system to save all process informations to database, but how I call some method to save the processinstance ? need I call jbpmContext.close() to end a certain workflow instance?

[mputz]

Look at the javadoc for JbpmContext to see the correct usage of JbpmContext. jbpmContext.close() should always be called within a finally clause. This ensures that the Hibernate session and connection is properly closed.

Regards, Martin

[cron1]

I have seen the javadoc before, and I can't use jbpm in that way because if you close a jbpmContext, you must reactive it by call createJBpmContext(), which is a resource costing process for applications. if we do that, the system will be very slowly.

our system have 100-300 clients accessed cocurrentlly.

[kukeltje]

So you want a webapplication with saving all data each step but without any overhead. Keeping a context open lead to lots of other issues with none-connection oriented webapps. e.g. When do you close it if the user just click the x on his browser? When the session times-out? In that case it is also resource intensive but in another way.

100-300 clients accessing concurrently to me is <1 db query per second, so I do not realy see a problem there

Creating and opening a context each time should not be expensive (depending on , creating a JbpmConfiguration each time is.

[mputz]

Creating a jbpmContext is a lightweight operation, basically it is a wrapper for a Hibernate transaction.

Regards, Martin

[estaub]

cron,

I think the key question is: "what happens next"?
If you're going to synchronously continue processing on the same process instance, then did you really need to commit it to the db at this point in time? If not, then don't do anything - just close it later. JBPM generally takes this approach - if multiple nodes and transitions can be executed synchronously, by default it won't commit any until all are done. This is a lot more efficient because it allows object caching across nodes within the transaction.

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.

-Ed Staub

[cron1]

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?

[kukeltje]

The context should not be shared!!! Open it and close it per webrequest as you mention further on. What do you mean by different PO's for different clients? Do they all work on the same processinstance at the same time? Or do you have multiple tasks parallel tasks for different actors? In that case the taskvariables are created at the moment the task is created with the values of processvariables of that moment. Changes in those are not reflected in the already created tasks.

[cron1]

There several actors do the workflow instance in the same phase of node or different task which execute by different swimlane. in that case, taskvariables can't be shared ?

the context can not be shared ? oh My God.

[kukeltje]

Oh jesus, what a complaints.....

Yes they can, by not declaring variables on the tasknodes you have access to the processcontext variables. Those are shared

[kamleshkr]

"JBPM generally takes this approach - if multiple nodes and transitions can be executed synchronously, by default it won't commit any until all are done."

Can you tell me how to change this default behaviour of jBPM?. I want to save the processinstance after execution of each node. Can i do anything in actionhandler for that?