In the start process of the scope activity, the scope activity status is changed to (Executingwait), the transaction is committed and, a new transaction is started. After that, the activity defined in the scope activity is executed. At this time, the transaction is not controlled by the activity defined in the scope activity.

In the end process of the scope activity, the scope activity status is changed to (Completedwait), transaction is committed and, a new transaction is started. After that, the status of the scope activity is changed to (Completed). At this time, there is status transition but the transaction is not committed.

The following figure shows the scope of transaction when the scope activity is completed successfully:

Figure 3-38 Scope of transaction when scope activity is completed successfully

Reference note

Describes the scope of transaction control of the scope activity that controls transaction.

• Transaction is not controlled in the activity defined in the scope activity that controls transactions.
• Transaction is not controlled in the activity that processes faults of the scope activity that controls transactions.
• Transaction is not controlled in the activity that is defined after the scope activity that controls transactions.

The following figure shows the scope of transaction control of the scope activity that controls transactions:

Figure 3-39 Scope of transaction control of the scope activity that controls transactions

When a system exception occurs in the scope activity, the scope activity rolls back till the point where the transaction is committed (reception: rolls back till Completed, scope: (Executingwait), and then sets error occurrence (Error) in the status of the scope, and commits transaction.

The following figure shows the scope of transaction when a system exception occurs in the scope activity:

Figure 3-40 Scope of the transaction when a system exception occurs in the scope activity

When a system exception occurs in the activity defined after the scope activity, the scope activity rolls back till transaction is committed (scope activity: (Completedwait)).

The following figure shows the scope of transactions when a system exception occurs in the activity defined after scope activity:

Figure 3-41 Scope of transactions when a system exception occurs in the activity defined after the scope activity

When a fault occurs in an activity that is defined in the scope activity that controls transactions and the fault is notified to the scope activity that controls transactions, the scope activity rolls back till the transaction is committed (receive: Completed, Scope: Executingwait).The process for activity defined in the scope activity is cancelled.

Based on the definition of the fault handler, if you execute the corresponding activity, the status of the scope activity becomes (Faulting). At this time, there is status transition, but the transaction is not committed.

At the time of notifying fault to the parent scope activity, the status of scope activity becomes (Faulted). Again, only status transition is performed, but the transaction is not committed. After notifying a fault to the parent scope activity, the operation is same as that of a scope activity that does not control transactions.

The following figure shows the scope of a transaction when a fault occurs in the scope activity:

Figure 3-42 Scope of transaction when a fault occurs in the scope activity

Based on the definition of the fault handler, if you execute corresponding activity and if a system exception occurs, the scope activity rolls back till the executing status (Executingwait).

The following figure shows the scope of a transaction when a system exception occurs after a fault occurrence:

Figure 3-43 Scope of transaction when a system exception occurs after a fault occurrence