A transaction is an environment where it is possible to COMMIT some or all of the operations performed within it, or to ensure that all of them fail.
In general, three transaction phases exist:
- build-up, during which the database operations are requested
- prepare, during which the transaction is validated
- commitment, during which the operations performed in the transaction are written to disk.
Note: Read-only transactions have only two phases: build-up and prepare.
Transaction build-up, which may be started explicitly or implicitly; prepare and commitment are both initiated explicitly through a request to commit the transaction (using COMMIT).
In interactive application programs, build-up takes place typically over a time period determined by the user, while prepare and commitment are part of the internal process of committing a transaction, which occurs on a time-scale determined by machine operations.
The transaction begins by taking a snapshot of the database in a consistent state.
During build-up, changes requested to the contents of the database are kept in a write-set and are not visible to other users of the system. This allows the database to remain fully accessible to all users. The application program in which build-up occurs will see the database as though the changes had already been applied. Changes requested during transaction build-up become visible to other users when the transaction is successfully committed.
A major function of the transaction handling in Mimer SQL multi-user systems is concurrency control. This means protecting the database from corruption which might arise when two users attempt to change the same information at the same time.
See the Mimer SQL Programmer's Manual, chapter 9, Transaction Handling and Database Security, for a more detailed discussion of transaction handling and database security.
Upright Database Technology AB
Voice: +46 18 780 92 00
Fax: +46 18 780 92 40