Database_transaction

A database transaction is a unit of work performed against a database management system or similar system that is treated in a coherent and reliable way independent of other transactions. 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 ensure the integrity of data is maintained. 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 commited. 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.

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 [1] and the newest version of the Microsoft NTFS filesystem both support transactions [2], but file system transactions are rarely used in practice due to lack of compatibility with older systems.

See also

• Distributed transaction
• Nested transaction
• ACID properties
• Atomic transaction
• Software transactional memory
• Long running transaction
• Transaction processing

External links

• Transaction Processing

This database-related article is a stub. You can help Wikipedia by expanding it.

This article is licensed under the GNU Free Documentation License. It uses material from Wikipedia