3 Replies Latest reply on Dec 2, 2005 6:15 PM by Koen Aers

    Concurrent changes/execution

    Rainer Alfoeldi Novice

      Hi all,

      maybe someone can help me out before I trace the code myself.

      Does concurrent (real async, > 1 thread) execution of tokens and subsequent changes to the tokens themselves effect the processInstance or any other persisted classes in a way that would result in concurrent change problems?

      In other words is it sufficient to lock on the token? Locking on the processInstance would i.e. serialize the execution of potentially long running actions.

      Greetings

      Rainer

        • 1. Re: Concurrent changes/execution
          Koen Aers Master

          Rainer,

          Normally pessimistic locking on the ProcessInstance is just fine. In general transactions in jbpm are not very long running. If you do have long running transactions e.g. in synchronous action executions, you could opt for optimistic locking, but then you would have to adapt the jBPM database schema to include the versioning.

          Regards,
          Koen

          • 2. Re: Concurrent changes/execution
            Rainer Alfoeldi Novice

            Hi Koen,

            thanks for the reply.

            Normally locking on ProcessInstance would be ok. What I'm doing is hooking up an imaging server to a legacy workflow system to a host to another host to whatever the business people in a large international bank may come up with.

            All of these calls spend more time in the remote systems then actually doing anything.

            If its on the top of your head: is locking on Tokens enough? If you don't know, I'll check it out next week anyway and post the result. It's just that I'm not a hibernate crack, so it will take a while.

            Good night

            Rainer

            • 3. Re: Concurrent changes/execution
              Koen Aers Master

              Well this depends. If signalling a token on one path of execution does not modify process variables or other state that is used by other, parallel paths of executions, this should be ok. If not, locking the processInstance is the only option, but you could go for optimistic locks in this case...

              Regards,
              Koen