A mechanism for committing a consistent set of changes into a database atomically.
Transactions are the primary unit of concurrent work on a database, allowing a set of changes to be committed into the database atomically. Most database systems guarantee a set of invariants within a transaction called ACID properties.
Atomicity guarantees that all changes in a transaction guarantees that all changes in the transaction will be committed or rolled back - a transaction is never partially applied.
Consistency guarantees that the transaction cannot leave data in an invalid state, including validity checks applied by database constriants.
Isolation guarantees that a transaction cannot interfere with data being used by another transaction. In practice, this constraint is often relaxed to trade consistency for performance by setting the isolation level of the transaction.
Durability guarantees that if a transaction is reported to the client as being committed that the database manager can guarantee that transaction has been committed and the changes stored permanently.
Within a simple transaction the semantics implied by ACID are fairly straightforward, but they can get more complex with more complex transaction semantics.
Distributed transactions guarantee ACID properties across multiple database systems or other resource managers for a transaction through a protocol known as two-phase commit. In this type of protocol each resource manager1 is asked to guarantee the ability to commit and then subsequently asked to actually commit the transaction. The transaction is not reported as committed until all resource managers have reported successful commits.
Nested or chained transactions allow parts of a transaction to be committed, but then rolled back if an error is encountered at a higher level. Rollback at any level aborts the whole transaction. This mechanism is useful for ensuring consistency across a complex transaction involving multiple operations.
Autonomous transactions allow certain updates to break off from the parent transaction context and commit autonomously. This is useful for (for example) ensuring that loggng information persists when an error causes the rollback of a parent transaction. Not all DBMS platforms support autonomous transactions.
The definitive book on transaction processing systems architecture is Grey and Reuters Transaction Processing: Concepts and Techniques (ISBN 978-1558601901).
1In transaction processing terminology a resource manager is something like a database management system that participates in a distributed transaction.
