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

    ActivityInstances: configurable, always or never

    Tom Baeyens Master

      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.