[jboss-user] [jBPM Users] - Re: jBPM 4 and thread-safeness

greeneagle do-not-reply at jboss.com
Fri Sep 11 14:14:29 EDT 2009


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#4254836

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4254836



More information about the jboss-user mailing list