Database - Transaction

In the context of databases (“transactional databases”), a transaction is a logical, atomic unit of work that contains one or more SQL statements. A transaction groups SQL statements so that they are either all committed, which means they are applied to the database, or all rolled back, which means they are undone from the database.

Transactions provide an “all-or-nothing” proposition, stating that each work-unit performed in a database must either complete in its entirety or have no effect whatsoever.

Further, the system must isolate each transaction from other transactions, results must conform to existing constraints in the database, and transactions that complete successfully must get written to durable storage.

All transactions must comply with the basic properties of a database transaction, known as ACID properties. A database transaction, by definition, must be atomic, consistent, isolated and durable.

A database transaction consists of one or more statements. Specifically, a transaction consists of one of the following:

• One or more data manipulation language (DML) statements that together constitute an atomic change to the database
• One data definition language (DDL) statement

A transaction has a beginning and an end.

A single transaction consists of one or more independent units of work, each reading and/or writing information to a database or other data store. When this happens it is often important to ensure that all such processing leaves the database or data store in a consistent state.

Examples from double-entry accounting systems often illustrate the concept of transactions. In double-entry accounting every debit requires the recording of an associated credit. If one writes a check for €100 to buy groceries, a transactional double-entry accounting system must record the following two entries to cover the single transaction:

• Debit €100 to Groceries Expense Account
• Credit €100 to Checking Account

A transactional system would make both entries — or both entries would fail. By treating the recording of multiple entries as an atomic transactional unit of work the system maintains the integrity of the data recorded. In other words, nobody ends up with a situation in which a debit is recorded but no associated credit is recorded, or vice versa.

Transactions in a database environment have two main purposes:

• To provide reliable units of work that allow correct recovery from failures and keep a database consistent even in cases of system failure, when execution stops (completely or partially) and many operations upon a database remain uncompleted, with unclear status.
• To provide isolation between programs accessing a database concurrently. Without isolation the programs' outcomes are possibly erroneous.

A simple transaction is usually issued to the database system in a language like SQL wrapped in a transaction, using a pattern similar to the following:

• Begin the transaction
• Execute several data manipulations and queries
• If no errors occur then commit the transaction and end it
• If errors occur then rollback the transaction and end it

• database transaction
• Oracle Transactions