-
1. Re: JbpmContext: when to create new vs. get current
brado Sep 21, 2006 11:03 PM (in response to 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 -
2. Re: JbpmContext: when to create new vs. get current
jinguo.yin Sep 23, 2006 10:29 AM (in response to brado)I fall across this problem also;
-
3. Re: JbpmContext: when to create new vs. get current
jstachera Oct 10, 2006 8:06 AM (in response to brado)It would be great if somebody could answer this question ^^^^^
-
4. Re: JbpmContext: when to create new vs. get current
jagadeeshrao Oct 13, 2006 3:27 AM (in response to brado)I am also facing this problem.
JD -
5. Re: JbpmContext: when to create new vs. get current
jeanguyer Oct 13, 2006 4:25 AM (in response to brado)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. -
6. Re: JbpmContext: when to create new vs. get current
brado Oct 13, 2006 10:31 AM (in response to 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 -
7. Re: JbpmContext: when to create new vs. get current
brado Oct 13, 2006 7:52 PM (in response to 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 -
8. Re: JbpmContext: when to create new vs. get current
grimshieldsson Oct 14, 2006 3:10 AM (in response to brado)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.
-
9. Re: JbpmContext: when to create new vs. get current
wangxin Oct 18, 2006 4:55 AM (in response to brado)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.