jbpmContext in Web Application

[symmetrysolutions]

I am watching several threads right now where there is confusion over the proper way to hold on to (or not hold on to) a jbpmContext within a Web application. Can someone that is familiar with jBPM internals shed some light on this subject?

A few questions:

1. Should a jbpmContext be created for every Web request? If so, does that mean that we can not put a process instance into a session and signal it across multiple Web Requests?

I believe you can not signal a process instance once the jbpmContext in which it was loaded is closed (even without for update)?

2. Is it OK to put the jbpmContext in the web session context? If so what is downside of doing this?

My main purpose of this is to be able to put the process instance in a users session and be able to set variables and signal tokens across multiple web requests.

Thanks for your help.

[kukeltje]

1: Yes

Correct, just like in real life... How can you tell someone to do something if he/she is not with you

2: No, only if it is closed things are saved, why would you put it in the sessioncontext in the first place. Creating a new one is fast.

3: Put the tokeId/processId in the context and use the jbpmContext to retrieve the process and act on it.

btw... I'm curious where you did find the threads with confusion on thoontho to the context. You could hold on to it, but with lots of possible problems... session timeouts, things not saved etc....

[symmetrysolutions]

Thanks for your reply and confirming what I had already suspected. I guess the context is exactly like a cached database connection where you get it and release it usually within a single method or operation.

The only thing I find a little strange is that I should not get a process/task instance and then hold on to it within my session. The reason this is desirable is because the process and task instance holds state information that I would like to reference and possibly update during that session not just a single request. I would think that there may be performance issues if I have to load it every time I want to change it.

Any thoughts on this?

[kukeltje]

Yes, you see the workflow more as a wizard. Use pageflow for that. Different workflow sequential tasks are normally not acted upon by the same user, so the advantage of caching is null.

[symmetrysolutions]

Not really, I see the workflow as a container for managing a long running transaction which may may have different users or different operations acting upon it within its life cycle.

The issue is not one of cache but one where at any one wait state the Web application needs to maintain the task, use/set variables on that task and then signal it to move on. While it is in one wait state it is not a single page operation that is getting/setting the values. I really do not want to have to copy the values out of the task into another container and then copy them back in when I want to save the task. The task is the container that maintains state so why should I not be able to hold on to it across contexts.

When the default persistence is used, a task or process instance within jBPM seems to be closely coupled to a transaction which is not typical for a workflow engine. It is not a criticism just an observation and one that the developer needs to be aware of and design their application to handle. Of course I could write my own persistence but then I would lose all of the hard work the JBPM team has put in.

The behavior I was expecting was that if I used one of the "ForUpdate" methods then the instance was closely coupled to a transaction. If I simply loaded it then I was responsible for saving it but could do so across any context.

I am just trying to fully understand the operations that effect design decisions within my applications when I use jBPM. I still plan on using it as I am a big supporter of anything from JBoss.

[kukeltje]

Longrunning transactions should not be stored in a session... but in a reference and fixed at the protocol level (locking etc.., see the ws-* standards)

The web application should only concentrate on one task, and what you describe is a kind of wizard. Multiple pages committing data to one task. Copying them over should not be for you to worry, but the container and api of the engine (and it does that for you). Varibables for tasks are stored separately and only when ' committed' (task is finished) they are copied to the processlevel again.... so I do not see a problem here.

I think you should look at things from a different perspective. Writing your own persistece in addition to jBPM is not strange. We've developed our own domain models for different apps with persistency and use jBPM to control some flow. We maintain relations between the flow and our domain model by storing the processid and relevant tokeid's in our domainmodel

[symmetrysolutions]

OK, I agree with your last comment (not to imply that I disagreed with other comments) since I would only store information that is relevant to process flow in a task or process variable. All other information would be stored using my own persistence of my own domain objects.

You mentioned "Copying them over should not be for you to worry, but the container and api of the engine (and it does that for you). Variables for tasks are stored separately and only when ' committed' (task is finished) they are copied to the processlevel again.... so I do not see a problem here."

You mean copying them from the task to the process instance?

But if I can not hold on to a task across contexts then I have to copy any working task variables out of the task and into my own session container, is that correct?

Again, I guess this is not that big of a deal since I would not use the task or process instance as a container for application data only for values that are relevant to process flow.

The BPM engine that I have been using has a logon/logoff session model and I guess I just got used to being able to retain whatever process objects I wanted in the session. It is just a matter of understanding jBPM operational requirements and changing my thinking. Your comments have been helpful.

[kukeltje]

You mean copying them from the task to the process instance?

Correct

But if I can not hold on to a task across contexts then I have to copy any working task variables out of the task and into my own session container, is that correct?

Correct again

Again, I guess this is not that big of a deal since I would not use the task or process instance as a container for application data only for values that are relevant to process flow.

As do we, good choice, I get the impression you ' see' it ;-)

The BPM engine that I have been using has a logon/logoff session model and I guess I just got used to being able to retain whatever process objects I wanted in the session.

I know one like this as well from the past... SW?

It is just a matter of understanding jBPM operational requirements and changing my thinking. Your comments have been helpful.

Great.... good luck