In this context, the term "transaction" refers to a logical operation involving multiple physical operations on one or more files which should be performed as a single unit (all or nothing). For example, posting a payment to an account may involve updating a receipts file, an open items file, and also changing a balance in the customer master file. You don't want those to get out of sync, so if an error occurs somewhere in the middle of the transaction, you want to back it all out. Transactions support gives you just this capability via the TRANSACTION'BEGIN, TRANSACTION'COMMIT, and TRANSACTION'ROLLBACK statements (described separately above).
Transactions require that all file updates be logged. The log makes is possible for the TRANSACTION'COMMIT and TRANSACTION'ROLLBACK commands to either make permanent or discard the changes since the TRANSACTION'BEGIN. So in order to use transactions, you must first open a log file (with TRANSACTION'LOG'OPEN).
Some additional notes about transactions:
| • | All records involved in the transaction remain locked until either the TRANSACTION'ROLLBACK or TRANSACTION'COMMIT statements. For this reason, you probably want to minimize the time spent in the transaction. |
| • | The log file keeps a record of every ISAM-A operation that alters data, whether a transaction is in progress or not. (See discussion of the recovery feature following for an explanation why.) Thus, it can grow rather quickly, so you will need to develop a strategy for deleting it (preferably just after making a complete data backup). |
| • | If a transaction has started and the program ends without executing the TRANSACTION'COMMIT or TRANSACTION'ROLLBACK, then TRANSACTION'ROLLBACK will be executed automatically (on the assumption that your program aborted and you failed to trap the abort). This does not apply to SBXs; only to main programs (RUN and LIT modules). |
| • | In most cases, you would use a single log file for an entire application, although in some specialized circumstances it might make sense to maintain separate log files for individual users. (The danger there is that actions by other users may affect the context of transactions, compromising the ability to replay them.) |
