-
1. Re: jBPM 4 and thread-safeness
kukeltje Sep 11, 2009 4:02 AM (in response to greeneagle)Wrong forum... Wow... never thought I would say that in the user forum... hahaha... good questions but more something for the dev forum. I'm not into the low level details of this so I'll ask others to respond.
(already did) -
2. Re: jBPM 4 and thread-safeness
tom.baeyens Sep 11, 2009 4:16 AM (in response to greeneagle)good question/remark.
event listeners threadsafety in jbpm has a different meaning then threadsafe in general java. so therefor, we should indeed update the docs and not use the word threadsafe for it.
in strickt java sense, nutable methods on threadsafe objects should be synchronized. in jbpm sense, the only requirement is that you don't change your member fields in the execute method. setters of event handlers don't have to be synchronized as this is done during initialization before jbpm will use the object.
in jbpm 3, a new delegation object was instantiated *for every usage* of an action (event listener). in jbpm 4, we want to get to a situation that the event listener object becomes a part of the process definition object graph. and hence it gets cached and used by all threads.
hth -
3. Re: jBPM 4 and thread-safeness
kukeltje Sep 11, 2009 4:24 AM (in response to greeneagle)Now THIS is what I call support...
and I think (!) it is true for actionhandlers as well and decisionhandlers and .... -
4. Re: jBPM 4 and thread-safeness
greeneagle Sep 11, 2009 2:14 PM (in response to greeneagle)First of all thanks for the fast response :-)
If this is the wrong forum for this kind of question could you please move the thread to the dev-forum? ...because I still have some questions concerning this issue.
in strickt java sense, nutable methods on threadsafe objects should be synchronized. in jbpm sense, the only requirement is that you don't change your member fields in the execute method.
I totally agree to that approach. It's the same as the singleton-model in spring. The threadsafeness (even more: reintrance) is guaranteed if the developer observes some basic rules. If he does not strange things may occur.
in jbpm 4, we want to get to a situation that the event listener object becomes a part of the process definition object graph. and hence it gets cached and used by all threads
How can you handle this? IMHO this strategy only can work if the member variables of a handler-impl are set with constant values. Since it is possible to inject dynamic values in a member-var (e.g. return values from a prior method-call) it will have the same effect than changing the member fields in the handler-class itself.
For better explanation of what I mean a short piece of code (sorry it is JBPM 3-style but I am atm still a rookie in JBPM 4 :-( )// in class A I create a ProcessDefinition ProcessDefinition pd = new ProcessDefinition(...); // now I start a couple of instances of class B (which extend Thread) // and start the threads for(int i = 0; i < 100; i++) { new B(pd).start(); } // class B looks something like that: public class B extends Thread { private ProcessDefinition pd; public B(ProcessDefinition pd) { this.pd = pd; } public void run() { //Note that I start the ProcessInstance depending on the same ProcessDefinition-instance ProcessInstance pi = new ProcessInstance(this.pd); pi.signal(); } }
In JBPM 3 an action-delegate was instantiated at first access. After that the already instantiated object was used:// snippet from Delegation public Object getInstance() { if (instance==null) { instance = instantiate(); } return instance; }
So if I understood you right the behaviour must be the same than in JBPM 4 after the point of the instantiation of the delegate.
This code produces the result I explained before:
If the member-fields of the used handlers are only set with constant values everything works fine
If the member-fields are set dynamically (e.g. via expressions) it becomes broken
And now the big question:
Have I understood something wrong or is this kind of test-scenario (multiple threads using the same ProcessDefinition-instance for instantiating ProcessDefinitions a kind of operation outside the specification?