Is it possible to do on-demand process-instance or ksession persistence? If so, is there any sample code?

I read that the work flow engine uses the single thread (the thread that starts the process/fires an event) to execute the entire process...no real multi-threading. What happens when the process instance and/or session is persisted at safe-points (or manually)?..does the thread end/return back to main program?

If I have to start multiple (many) processes at the same time from the main program, do I have to start them all in different threads? do I have to model my own thread pool?

I have a situation where, the main program receives a message on http and the http response thread have to be returned with status 200 OK after persisting the message. If I want the message persistence as a part of the process, how can I achieve this? I mean, I cannot return the main thread just after the first (persistence) node of the process, right?...how can make the rest of the process continue?

There is currently work in progress to ensure that jBPM will work with any JPA provider and hopefully will be released soon, so any help with testing that is more then welcome

Kishore Jaladi wrote:

Is it possible to do on-demand process-instance or ksession persistence? If so, is there any sample code?

You can control your transactions so I think you could achieve on demand persistence if I got you question right...

Kishore Jaladi wrote:

I read that the work flow engine uses the single thread (the thread that starts the process/fires an event) to execute the entire process...no real multi-threading. What happens when the process instance and/or session is persisted at safe-points (or manually)?..does the thread end/return back to main program?

Yes, as soon as process goes into a state node (human task, timer, catch events) it will return the thread to main program.

Kishore Jaladi wrote:

If I have to start multiple (many) processes at the same time from the main program, do I have to start them all in different threads? do I have to model my own thread pool?

It all depends on your process design. If your process has a state node just after start event (such as human task) you could use single thread to start them but they will be started in sequence.

Kishore Jaladi wrote:

I have a situation where, the main program receives a message on http and the http response thread have to be returned with status 200 OK after persisting the message. If I want the message persistence as a part of the process, how can I achieve this? I mean, I cannot return the main thread just after the first (persistence) node of the process, right?...how can make the rest of the process continue?

>>There is currently work in progress to ensure that jBPM will work with any JPA provider and hopefully will be released soon, so any help with testing that is more then welcome

I sure can sign up for testing MongoDB with Datanucleus. I am currently using 5.1.1.Final. Is that fine? or should I use another version. let me know.

>>You can control your transactions so I think you could achieve on demand persistence if I got you question right...

Do you mean that the auto-persistence kicks in just before a transaction begins/ends? if so, is it at the beginning or the end?

>> Yes, as soon as process goes into a state node (human task, timer, catch events) it will return the thread to main program.

I C. By State node, do you mean anything that puts the process in the "Wait" mode?

When the state node changes (receives the event via signal event, human task etc.) does the process continue in a different thread? I mean, lets say I do the following in the main thread with a process that has start->catch-event->...

1. Does the above last statement block the main thread until the "test" proces is complete? or does it start in a differnt thread?

2. Also, slightly tangential, is a Task item with executeWorkItem not including manager.completeWorkItem(.., ..) is also equivalent to a state node, in the sense that does it keep the process in "wait" state. Isnt that how sendTask and receiveTask work? or am I totally off? Can you please point me to any example that uses sendTask and receiveTask?

The complete flow on using the Async handlers with a new thread spawned int he executeWorkItem is not clear to me. So, in the example code snippet in that doc, does the process go into"wait" state because the "executeWorkItem" does not completeWorkItem()?...and if so, how is the async thread supposed to mark the work item complete? is there any example?

>>There is currently work in progress to ensure that jBPM will work with any JPA provider and hopefully will be released soon, so any help with testing that is more then welcome

I sure can sign up for testing MongoDB with Datanucleus. I am currently using 5.1.1.Final. Is that fine? or should I use another version. let me know.

Great, I have seen your other post about and looks like you're already on it maybe it would be better for you to grab 5.3.0-SNAPSHOT for your tests as most likely with 5.2 you will run into hibernate specific annotation issue that was fixed in 5.3.

Kishore Jaladi wrote:

>>You can control your transactions so I think you could achieve on demand persistence if I got you question right...

Do you mean that the auto-persistence kicks in just before a transaction begins/ends? if so, is it at the beginning or the end?

I am not sure I understand what is auto persistence, could you please elaborate bit more?

Kishore Jaladi wrote:

>> Yes, as soon as process goes into a state node (human task, timer, catch events) it will return the thread to main program.

I C. By State node, do you mean anything that puts the process in the "Wait" mode?

When the state node changes (receives the event via signal event, human task etc.) does the process continue in a different thread? I mean, lets say I do the following in the main thread with a process that has start->catch-event->...

1. Does the above last statement block the main thread until the "test" proces is complete? or does it start in a differnt thread?

Yes, that is what I meant by state node. Thread that called signalEvent will be used to execute all the logic till the next state node or the end of the process.

Kishore Jaladi wrote:

2. Also, slightly tangential, is a Task item with executeWorkItem not including manager.completeWorkItem(.., ..) is also equivalent to a state node, in the sense that does it keep the process in "wait" state. Isnt that how sendTask and receiveTask work? or am I totally off? Can you please point me to any example that uses sendTask and receiveTask?

Exactly, if work tiem handler will not call completeWorkItem it will remain in a wait state until it is completed with that method. Send and receive tasks work item handlers are simple (more for demo purpose) currently, if you like more advanced work item handler take a look at human task handler that can be found in jbpm-human-task module in org.jbpm.process.workitem.wsht package

The complete flow on using the Async handlers with a new thread spawned int he executeWorkItem is not clear to me. So, in the example code snippet in that doc, does the process go into"wait" state because the "executeWorkItem" does not completeWorkItem()?...and if so, how is the async thread supposed to mark the work item complete? is there any example?

Yes, this is exactly what happens. You should pass work item manager to the async handler to execure completeWorkItem as soon as you're done with processing.