Write Transactions and Recovery

A write transaction in C/SIDE is defined as an atomic unit of work on the database which is either completed entirely or not at all. In other words, a transaction is a way to encapsulate a sequence of read and write operations on the database in order to ensure that either all or none of the operations is performed. The concept of write transactions is a general C/SIDE feature that is used both in single- and multiuser environments.

Ensuring Data Consistency

When a transaction has been submitted to the C/SIDE DBMS (Database Management System), the system is responsible for making sure that:

  • All the transaction operations are completed successfully and their effect is recorded permanently in the database.

    - or -

  • The transaction has no effect on the database. The DBMS must prevent the following situation from occurring: some of the transaction operations are applied to the database while the other operations in the same transaction are not applied. A situation like this could occur if a transaction fails while executing.

Some typical reasons for a transaction to fail are:

  • The user decides to abort the transaction.

  • The transaction cannot be completed because some information is missing.

  • The system crashes, due to hardware or software errors.

  • There are operation errors, such as overflow or division by zero.

If the transaction is aborted, all the tables are restored to the state they were in before the transaction started.

A typical example of a write transaction would be transferring $100 from one account to another. This involves two operations in a single database:

  1. Subtract $100 from account A.

  2. Add $100 to account B.

If a power failure or some other fatal error interrupts the program after the first operation, the database is not in a consistent state, because the second operation has not been completed. However, bundling both operations into a single transaction ensures that either none or both of the operations are executed and the data will always be consistent.

Write Transactions

The previous section explained that the database will always be consistent regardless of whether a transaction is committed or aborted. The way C/SIDE handles write transactions and keeps the database consistent is different from traditional approaches. Traditionally, database systems have a feature that automatically maintains a log file which records all changes to the database. This log file contains images of a record before it is modified and after it is modified—"before" and "after" images. The changes recorded in the log file can be used to recover the database if failures occur.

Assume that an application program aborts because of power failure or is aborted by the operator. The database is now in an inconsistent state, and all the modifications that were already made to the database must be canceled. In common database systems this is achieved by so-called rollback recovery, that is, by backing out the updates of the application program. This rollback is performed by reading the log file backwards and undoing the recorded changes to the database, until the point where the application program started. This restores the modified records to their original contents.

The C/SIDE DBMS does not need to use a log file because the C/SIDE database is data version oriented. This means that each time a transaction is committed, a new version of the database is created. While you enter new data in the database your changes are private; not until you commit the changes, does the new data become public and establish the newest version. The DBMS allows different applications to access and modify the database concurrently by letting them work on individual versions that are snapshots of the database taken at the point in time where the applications start to access the database. The advantages of the data version approach will become clear as you read through the following sections.

See Also

Concepts

Read Consistency and Concurrency