Nested Transactions (Magic xpa 4.x)
When a parent task calls a child task the following behavior can occur:
|
|
|
|
|
Deferred/Nested Deferred
|
Physical
|
The child transaction opens a physical transaction. The updates are sent to the database independent of the parent task.
|
|
Deferred/Nested Deferred
|
Deferred
|
The child transaction runs within the parent’s transaction. The Data Manipulation (DM) statements of the child task are sent only when the parent task commits.
|
|
Deferred/Nested Deferred
|
Nested Deferred
|
The child task opens as a new deferred transaction. Its transactions are committed to the database independent of the parent task.
|
|
Physical
|
Physical
|
The child task submits database updates with the parent after each record or task. Parent and child tasks share the same transaction.
|
|
Physical
|
Deferred or Nested Deferred
|
Runtime error.
|
A task that opens as a physical transaction can still have a deferred or nested deferred child providing that the parent does not actually open the physical transaction.
When a task is opened from an event handler that is defined for a different task, the transaction nesting is according to the Runtime transaction and not the Studio definitions.
For example:
Task A, defined as a deferred transaction, opens Task B, which is defined as a physical transaction. Task B updates the database as a physical transaction, and an event is triggered. The handler for this event is defined in Task A, and it calls Task C, which is a deferred transaction. Task C, a deferred transaction, cannot run under Task B, a physical transaction, and Runtime error occurs. If, however, Task C was defined as Within Active Transaction, it would have opened as a physical transaction, and no runtime error would have occurred.
