A database transaction is a unit of interaction with a database management system or similar system that is treated in a coherent and reliable way independent of other transactions. Ideally, a database system will guarantee all of the ACID properties for each transaction. In practice, these properties are often relaxed somewhat to provide better performance.

In database products the ability to handle transactions allows the user to ensure that integrity of a database is maintained.

A single transaction might require several queries, each reading and/or writing information in the database. When this happens it is usually important to be sure that the database is not left with only some of the queries carried out. For example, when doing a money transfer, if the money was debited from one account, it is important that it also be credited to the depositing account. Also, transactions should not interfere with each other. For more information about desirable transaction properties, see ACID.

A simple transactions is usually issued to the database system in a language like SQL in this form:

1. Begin the transaction
2. Execute several queries (although any updates to the database aren't actually visible to the outside world yet)
3. Commit the transaction (updates become visible if the transaction is successful)

If the transaction fails at any point before getting to the Commit phase, the database system will rollback any changes. All other transactions will behave the same way as if the transaction had never existed. The transaction can also be rolled back manually at any time before the commit.

Transactional databases

Databases that support transactions are called transactional databases. Most current databases (such as Mimer SQL, PostgreSQL, MySQL, Microsoft SQL Server and Oracle) fall into this category.

External links

• transaction processing: http://c2.com/cgi/wiki?TransactionProcessing

See also

• Distributed transaction
• Nested transaction
• ACID properties