How Do I Implement a Nested Transaction? (Magic xpa 3.x)
When you are using Deferred transactions, you might have a situation where one task has a transaction open, then calls another task which also opens a transaction. For instance, suppose you have a parent task that opens a transaction in Deferred, Before Record Prefix, and calls a child task which does the same.
However, all the actual commits in this case will happen at the same time, in the parent task. If you do a rollback at the child level, the child changes will be rolled back, and so will the changes done in the parent. The parent and child tasks share in the same transaction.
If you want the child task’s changes to be independent of those made in the parent, you will need to use a different kind of transaction, called Nested Deferred transactions, as shown below.
Here, Magic xpa caches the updates that were made by both the parent and the child task. The child task’s transaction gets committed before the child task exits. If a rollback is done in the child task, only the child task’s transactions are rolled back. The parent task’s transactions are handled separately, in the parent task.
This doesn’t implement a nested transaction in the native DBMS, but it has the same effect.
Note: The transaction type "Within Active” is used so the same subtask can be used by a task using either Physical or Deferred transactions, but it doesn’t implement nesting. A child task set to “Within Active” would work as in the first example, as if it were set to “Deferred”.
The Online and Rich Client Samples projects (program SQ04 and RSQ04)
