Database transaction

A database transaction is a unit of work performed within a database management system or similar system, against a database, that is treated in a coherent and reliable way independent of other transactions. The main purpose of transactions is two folded:
 * 1. 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.
 * 2. To provide isolation between programs accessing a database concurrenctly. Without isolation the programs' outcomes are typically erroneous.

A database transaction, by definition, must be atomic, consistent, isolated and durable. These properties of database transactions are often referred to by the acronym ACID.

Transactions provide an "all-or-nothing" proposition stating that work units performed in a database must be completed in their entirety or take no effect whatsoever. Further, transactions must be isolated from other transactions, results must conform to existing constraints in the database and transactions that complete successfully must be committed to durable storage.

In some systems, transactions are also called LUWs for Logical Units of Work.

Purpose of transaction
Databases and other data stores in which the integrity of data is paramount often include the ability to handle transactions to maintain the integrity of data. A single transaction is composed 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 the database or data store is left in a consistent state.

The concept of transactions are often demonstrated via double-entry accounting systems. In double-entry accounting every debit requires an associated credit be recorded. If you wrote a check for €100 to buy groceries at the local store a transactional double-entry accounting system would record the following two entries to cover the single transaction:


 * 1) Debit €100 to Groceries Expense Account
 * 2) Credit €100 to Checking Account

In a transactional system both entries would be made, or both entries would fail. By treating the recording of multiple entries as an atomic transactional unit of work you maintain the integrity of the data recorded. In other words, you will not end up with a situation in which a debit is recorded but no associated credit is recorded, or vice versa.

Transactional databases
Databases that support transactions are called transactional databases. Most modern relational database management systems fall into this category.

In a database system a single transaction might be composed of one or more data manipulation statements and queries, each reading and/or writing information in the database. Consistency and integrity of data is considered highly important in database systems. 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:


 * 1) Begin the transaction
 * 2) Execute several data manipulations and queries
 * 3) If no errors occur then commit the transaction
 * 4) If errors occur then rollback the transaction

If no errors occurred during the execution of the transaction the transaction is committed. A transaction commit operation applies all data manipulations within the scope of the transaction and persists the results to the database. If an error occurs during the transaction, or if the user specifies a rollback operation, the data manipulations within the transaction are not persisted to the database. In no case can a partial transaction be committed to the database since that would leave the database in an inconsistent state.

In SQL
A  statement in SQL or, on some systems, any statement that will modify data, starts a transaction within a relational database management system (RDBMS).

Any work done after this point will not be visible to other users, until a  statement is issued. A  statement can also be issued, which will undo any work performed since the   command. Both  and   will end the transaction: another   will need to be issued to start a new one.

Some database systems allow the synonyms  and  , and may have other options available.

Distributed transactions
Distributed transactions are implemented as transactions against multiple applications or hosts. A distributed transaction enforces the ACID properties over multiple systems or data stores, and might include systems such as databases, file systems, messaging systems, and other applications. In a distributed transaction a coordinating service ensures that all parts of the transaction are applied to all relevant systems. As with database and other transactions, if any part of the transaction fails, the entire transaction is rolled back across all affected systems.

Transactional filesystems
The Namesys Reiser4 filesystem for Linux and the newest version of the Microsoft NTFS filesystem both support transactions, but file system transactions are rarely used in practice due to lack of compatibility with older systems.