JbpmContext: when to create new vs. get current

[brado]

The general question: when should you create a new JbpmContext vs. get the current context?

The reason that this question hasn't been completely clear to me is because of a couple reasons:

1) It appears that any saving of data to the database (such as process instance state) doesn't commit until the JbpmContext is closed. This then seemed to suggest that a JbpmContext needed to be created and closed each time data needed to be saved to the database.

2) While I have seen documentation saying that JbpmConfiguration was re-entrant, I have seen no such indication that JbpmContext is. I wasn't sure that if I was working with a JbpmContext in a servlet (or several servlets) whether it would be safe for all of them to be operating simultaneously on the current jbpmContext, rather than all using their own jbpmContext instance for thread safety.

What is the recommended approach to using jbpmContexts? Can the "current" jbpmContext be used across multiple servlets and multiple threads without there being a problem, or does each one need to create its own jbpmContext, and how does this affect the committing of data to the database?

Thanks for your help,

Brad

[brado]

Does anyone have any inkling about the answer to this. This still seems to be a question for which the answer is elusive.

Thanks.

Brad

[jinguo.yin]

I fall across this problem also;

[jstachera]

It would be great if somebody could answer this question ^^^^^

[jagadeeshrao]

I am also facing this problem.

JD

[jeanguyer]

1) It appears that any saving of data to the database (such as process instance state) doesn't commit until the JbpmContext is closed. This then seemed to suggest that a JbpmContext needed to be created and closed each time data needed to be saved to the database.

i create a new JbpmContext each time i begin an transaction.
I use CMT mecanism.
I initialize my JbpmContext with a JbpmConfiguration get from JNDI(i use jbpm.sar)

Hope this helps.

Regards,
Jean.

[brado]

Jean,

Yes, that helps -- thanks for the reply. However, it still doesn't answer the big question which is whether JbpmContext is reentrant or not. If it is not reentrant, then I want to know what the purpose of the JbpmConfiguration.getCurrentContext() method is. If JbpmConfiguration is reentrant, which the documentation says it is, then there's the possibility of two threads simultaneously invoking getCurrentContext(), and getting a reference to the same JbpmContext. Somehow this doesn't seem right if JbpmContext objects are tied to transactions. It would seem to me that JbpmContext objects should not be reentrant, but a single instance should be isolated to a single thread (or even more properly, a single caller). It strikes me that having a getCurrentContext() method on a reentrant JbpmConfiguration is a bug, or a design flaw, however you want to state it.

Can someone clarify the situation here? This is an issue that's fairly fundamental to use of jBPM.

Thanks,

Brad

[brado]

Perhaps I've been a bit obtuse, and haven't properly phrased my question. But since its been over a month, and its obvious that others have the same question, I'll try to rephrase my question for jBPM developers and those who would consider themselves "experts" in jBPM:

How is it possible to use jBPM properly without knowing the answer to this question? How can one structure jBPM as a component in a server environment if it is unknown what the behavior of a jBPMContext is with regard to multiple simultaneous invocations?

Is everyone just shooting in the dark?

Thanks,

Brad

[grimshieldsson]

I'm using JBPM in a web app, and using the filter provided in JBPM to open and close the context. getCurrent, according to the documentation gets the current context for the currently executing thread. If you've gotten the context once, you shouldn't have to get it again in the same thread, unless you've closed it.

[wangxin]

I read the source code a little. It seems the current context is got from current thread stack. If the context is not avaialble, a new context will be allocated from the stack. I understand the context may not be re-entry, but it should be safe to use in the thread since each thread has different context.