Transaction mechanics
- Last Updated: January 16, 2024
- 2 minute read
- OpenEdge
- Version 12.8
- Documentation
Transaction mechanics
During a transaction, information on all database activity occurring during that transaction is written to a before-image (or BI) file that is associated with the database and located on the server with the other database files. The information written to the before-image file is coordinated with the timing of the data written to the actual database files. That way, if an error occurs during the transaction, the AVM uses the before-image file to restore the database to the condition it was in before the transaction started. Information written to the before-image file is not buffered. It is written to disk immediately, so that there is minimal loss of information in the event of a system crash.
Space in the before-image file is allocated in units called clusters. The AVM automatically allocates new clusters as needed. After all changes associated with a cluster are committed and written to the database itself, the AVM can reuse the cluster. Therefore, the disk space used by the before-image file depends on several factors including the cluster size, the scope of your transactions, and when physical writes are made to the database files. An action such as creating a huge number of database records in a batch procedure within a single transaction creates an enormous before-image file. You should avoid such actions.
When the AVM encounters a transaction block nested within another transaction
block, it starts a subtransaction. All database activity occurring during
that subtransaction is written to a local-before-image (or LBI)
file. Unlike the database BI file, the AVM maintains one LBI file
for each user. If an error occurs during the subtransaction, the
AVM uses this local-before-image file to restore the database to
the condition it was in before the subtransaction started. In any
case where a full transaction is not being backed out, the AVM uses
the local-before-image file to back out, not only subtransactions,
but also changes to variables not defined as NO-UNDO.
Because the LBI file is not needed for crash recovery, it does not have to be written to disk in the same carefully synchronized fashion as does the before-image information. This minimizes the overhead associated with subtransactions. The LBI file is written using normal buffered I/O. The amount of disk space required for each user's LBI file depends on the number and size of subtransactions started that are subject to being done. It is advisable that you minimize the use of subtransactions, as well as the scope of your overall transactions, not just to simplify the handling of these files but also to minimize record contention with other users.