2 Replies Latest reply on Jun 18, 2008 10:39 AM by porcherg

    ActivityInstances: configurable, always or never

    tom.baeyens

      ActivityInstances are an enhancement over jPDL 3. In jPDL 3 clients only have the token as a handle. In case there is a race condition between the timer and the external trigger, the client has no real way to determine if the timer came first.

      An activity instance represents one execution of a node. It also serves as a handle to the execution. When an activity instance is active, the corresponding execution is blocked. Then, all external triggers should be provided through the activity instance. The activity instance can then keep track of whether it has been completed or not.

      In case there is a race condition between a timer and an external trigger, the last one of those two that arrives will not find the activity instance in the DB or it will notice that an exception comes out of the activity instance cause it was already completed.

      An activity instance is a kind of execution scope that matches a node (potentially a composite node like a flow, sequence or a super-state).

      Process variables and timers can be associated to an activity instance. In the process definition, variable definitions and timer definitions can be associated to Nodes and ProcessDefinitions.

      At runtime, if a node has a local scope, an activity instance will be created. If a node has no local scope declared, no activity instance will be created. This keeps the performance good in case there are no external race conditions.

      Executions still are structured in a tree. Each execution has a stack of activity instances. Variable lookup will happen first through the stack of activity instances and then up the parent execution chain recursively.

      I opted to support both models: execution based signals and activity instance based signals. The drawback is that currently, the API's are not the same. For signalling an execution you do

      execution.signal();


      for signalling an activity instance, you do

      execution.getActivityInstance().signal()


      But the advantage is that we can now optimize. I believe that having an activity instance for every activity will harm performance significantly. And in most cases if timers are not present, it's not needed.

      Input always welcome. To be discussed further in Dublin.

        • 1. Re: ActivityInstances: configurable, always or never

          I'm probably missing something... but if the only purpose is to disambiguate races, might it be simpler to put a high-level "version" on the token that is incremented on each signal()? Callers that want to protect against races have to pass in the current version when they signal(). This would avoid the extra table.

          -ed

          • 2. Re: ActivityInstances: configurable, always or never
            porcherg

             

            "tom.baeyens@jboss.com" wrote:
            I believe that having an activity instance for every activity will harm performance significantly. And in most cases if timers are not present, it's not needed.


            ActivityInstances are needed to declare local variables (e.g. node variables).
            Do you think using ActivityInstances for every node that has local variables will have a big impact on performance ?

            regards, Guillaume