When a Model instance is executed, its execution is split in transactions: the model instance status is persisted on every transaction commit. Note that database transaction boundaries are bound to session boundaries.

When a model is instantiated, the following happens:

1. All its executable modules are instantiated.
2. The first database transaction for the model instance is created.
3. All BPMN and Goal processes in the executable modules are instantiated including any imported processes.
4. On Goal processes, all top goals are triggered and become either ready or running if their precondition evaluates to true. 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 a time slip (timer; signal, if the signal has not yet been received, etc.)
   • parallel join gateways that wait for a token

All moves of all tokens comprise one EJB transaction. The transaction is committed or rolled back and closed along with the session and the status of the model instance is persisted.

Important: Instances of shared Records are persisted in the Model instance as the entities' primary key and record type: however the value is stored in the respective database table and can be used by other Model instances or systems. In every new transaction, the system fetches the values of the shared Records from the database. Therefore consider the possible performance impact when working with large amounts of record instances.

If some tokens remained in the model instance, the model instance remains in the RUNNING state, but no actions are performed, the model instance is invoked (woken up) when some of the following happens:

• A human task is submitted.
• A Timer is triggered.
• A condition with 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.).

Transactions in a Model instance with two Process instances

The first transaction includes generating of tokens on None Start Events and moving them to the closest wait points; in this case, 3 human tasks. The system then waits for the tasks to be submitted. Note that the order of the transactions is just an example order and it depends on the order in which the human tasks are submitted and the condition evaluation time.

Example transactions in a single model instance with two process instances

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).