When a Model instance is executed, its execution takes place in transactions. The status of the model instance is persisted always when such a transaction is committed (it finishes).

To understand what comprises a transaction, let's go through model execution:

1. All modules are instantiated.
2. The first database transaction for the model instance is created.
3. All BPMN and Goal processes are instantiated.
4. On Goal processes, all top goals are triggered and become either ready or running depending on their precondition. The running Goals trigger their sub-goals or plans.
5. Tokens are generated on all start events of the relevant process instances and on activities with no incoming flows. Every token is moved as far ahead as possible, that is, until it hits a wait point. A wait point is considered the following:
   • asynchronous task (user task, web service task, etc.)
   • intermediate event that requires the execution to stop, such as a delay (timer; signal, if the signal has not yet been received, etc.)
   • parallel join gateways that wait for a token
6. If no token can be moved further, the transaction ends and is committed or rolled back in case of an error and the status of the model instance is persisted: if a token move fails with an exception, the branch execution on the branch is no longer invoked.

Important: Instances of shared Records are persisted in the Model instance using their primary key and record type: however, the value is stored in a database table. In every new transaction, the system fetches the values of the shared Records it requires from the database. This can potentially slow down the execution when working with large amounts of shared-record instances across multiple transactions.

A model instance with tokens remains in the RUNNING state and is invoked (woken up) whenever one of the following happens:

• A human task is submitted.
• A Timer is triggered.
• A condition that uses a shared record is met.
• A signal is received.
• A web service request/response is received.
• An asynchronous task is triggered.
• An Admin action occurs (an expression is evaluated, a context value changed, etc.).

On invocation, the following happens:

1. A new transaction and session are created based on the persisted model instance data. The persisted model instance data includes:
   • tokens with their positions
   • execution context (variables, referenced values, shared records)
2. Every token is "moved" as far ahead as possible until it hits a wait point.
3. Signals are handled, goals activated and deactivated, values changed, etc.
4. Every token is "moved" as far ahead as possible.

That means that an invocation is in general identical with one transaction; however, if a transaction can include a custom object, such as, a function, which can create its own transaction. Such a transaction is still part of the same invocation.

The transaction is committed or rolled back and closed along with the session (the status of the model instance is persisted).

Example Transactions in a Model instance with Two Process Instances

The order of the transactions is an example order and depends on the order in which the asynchronous tasks are accomplished.

• 1st transaction: None Start Events produce a token each; the tokens are moved as far as possible:

  • In process instance A, the token is moved to the Timer Intermediate Event with a delay (had it defined a point in time which has already occurred, the token would be moved further).
  • In process instance B, the token is moved to the first split gateway, which splits it into 2 tokens; The first token moves to the asynchronous task and waits for the task to be accomplished; the second token passed through the synchronous task and enters the join gateway, which holds it and waits for the first token to arrive.

  At this point, the tokens cannot move further and the transaction ends.

• 2nd transaction: we assume the delay period on the timer in A has elapsed;
  • In process instance A, the token is moved to the asynchronous task.
  • In process instance B, the token remains on the asynchronous task and the gateway keeps waiting for it.
• 3rd transaction: we assume that asynchronous tasks in both processes have been accomplished.
  • In process instance A, the token is moved to the first gateway and split in two:
    • The first token continues until the Timer Intermediate Event with a delay;
    • The second token continues until to the join gateway.
  • In process instance B, the token is enters the second join gateway. Since both tokens originally produced by the split gateway have arrived, the join gateway produces a token, which then continues to the asynchronous task.
• 4th transaction: we assume the delay set in the timer event in A has elapsed.
  • In process instance A, the token is moved to the second join gateway which has now received both tokens produced by the split gateway and hence produces a token. The token continues to the None Start Event, which consumes it and the process instance finishes.
• 5th transaction: we assume the asynchronous task in B has been accomplished.
  • In process instance B, the token is moved to the None Start Event, which consumes it and the process instance finishes.

Example transactions in a single model instance with two process instances