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. anonymous wrote : | 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. anonymous wrote : | 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? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4254836#... Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&a...