Many applications have the requirement to make a coordinated set of alterations to two or more resources.  For example, a financial application transferring funds between accounts must record a debit for one account and a credit for the other. Normally, these operations may be expected to complete without errors but the application needs a guarantee that if a process or system should fail then all or none of the operations will be effective. The standard solution to this problem is to use system software that provides a transaction-processing environment and define each coordinated set of alterations as a transaction.

A transaction is a series of file or database operations that is atomic (indivisible) with respect to recovery.  Transactions are initiated by an operation on a recoverable resource and terminated by a subsequent commit or a rollback. In some environments the terms unit-of-work, syncpoint and backout are used instead of transaction, commit and rollback respectively.

When a transaction is committed any alterations made by that transaction are made persistent (in the sense that they will be redone if necessary by a recovery procedure in the event of system failures). When a transaction is rolled back any alterations made by that transaction are undone. A transaction that is in progress at the time of a system or process failure will be rolled back by a recovery procedure.

In order to support the development of applications which require transaction processing, PROIV provides automatic commit scheduling based on PROIV Function structure, plus automatic rollback under defined error conditions. PROIV also provides logic statements for explicit commit and rollback control.

Section links:

Automatic Commit

Automatic Rollback

Controlling Commit and Rollback from Logic

Clearing Files

Transaction Isolation (Consistency) Levels

Comment on this topic

Topic ID: 720118