Transactions

9.0

A transaction is a file mechanism that allows a program to go through all the steps of updating files without actually writing the data until processing the last file of an operation is finished. This is useful in that it allows a program to detect potential errors in processing allowing the transaction to abort without having to go back and change all of the files that were updated back to their original state. Using transactions, data files are never left in an inconsistent state that may lead to processing errors later.

To illustrate how transactions are used, we will walk through the steps of a perpetual inventory system. In such a system, several data files are potentially updated by a single operation. During the sale of an item, the sale is recorded in one data file. The inventory file is then updated to reflect the sale. In the event that the inventory falls below a reorder level, the program can then post an order in a third file. If an IO error was to occur while updating the inventory file without transactions, the program would need to correct the sales file and notify the user of the error. If the whole operation was covered under a transaction, the program simply aborts the transaction and doesn’t have to worry about correcting the data files because nothing was written to the data files. When using transactions, all the data is written when the transaction is completed.

Sunbelt PL/B implements transactions to work as pessimistic transactions. Pessimistic Transactions lock all specified files for the duration of the transaction. If record locking is not used or the files in question have the potential of being modified by other programs, pessimistic transactions should be used. Files that are not listed as part of the transaction are not locked for the duration of the transaction. File operations still occur as they would outside a transaction with the exception that file writes are cached until the end of the transaction. If other programs change any of the files written to during the transaction, the transaction will fail. Care must be taken to make sure all files that are updated are listed as part of the transaction in order to ensure successful completion of the transaction.

To use record locking in transactions, the program must use the MULTIPLE unlock mode to ensure that modified records remain locked until the transaction is complete. The transaction commit that signifies the end of the transaction writes all the changes to the files and unlocks all records. Record locking may be used in a pessimistic transaction so long as the file is not specified in the list of files that is locked at the start of the transaction.

PL/B Transactions are not an accumulation of file operations but rather a cache of disk writes that are committed all at one time. It is important to remember this as cached writes of files that are neither pessimistically locked nor covered by record locks cannot be committed to disk as it is entirely possible that other programs could have modified the files. Such modifications could effect where the cached writes would be written and cached ISAM structures may no longer be valid. These situations will cause an IO error identifying the failure. The IO errors result in a ROLLBACK discarding all writes and updates done by the program. In such a case, a program would have to start the transaction over in order to write the data.

See Also: Disk I/O Instructions