gtpa2m1pApplication Programming

Outside the Commit Scope

Because the starting of a commit scope is under ECB control, you can implement TPF transaction services support without affecting the way existing applications run. However, existing applications may be impacted by applications using this support.

Finding Records

Normal find processing is not affected by TPF transaction services support.

Find-with-hold processing may be affected; see Holding Records for more information.

Filing Records

Normal file processing is not affected by TPF transaction services support.

File-with-unhold processing may be affected, however; see Holding Records for more information.

Holding Records

Although there are no API changes for processes that are outside of the commit scope, you need to understand what effect the commit scope has on them. For requests outside of the commit scope, a commit-level hold is viewed the same as an ECB-level hold. This means that if the requested record is held at the ECB level or the commit level, the request will be queued. This processing could result in an increase in record hold duration and an increase in record hold deadlock conditions.

For example, look at the scenario in Figure 15. Program A, which is using TPF transaction services support, causes a deadlock to occur.

Figure 15. Example of a Deadlock Condition


T1
Program A starts a root commit scope by entering a begin transaction.

T2
Program A gets a hold lock on record A. The lock is added to the commit scope.

T3
Program B gets a hold lock on record B.

T4
Program B requests a hold on record A; record A is still held by program A so the request is queued and program B waits.

T5
Program A files and unholds record A; the lock for record A is still held by the commit scope. Program B will continue to wait.

T6
Program A requests a hold on record B. Record B is held by program B, which is still waiting, so the request is queued and program A waits, resulting in a deadlock condition.