A transaction is a group of database operations treated as a single unit of work: either all of them take effect or none of them do. If everything succeeds, the transaction commits and its changes become permanent; if anything fails partway through, the transaction is rolled back and the database is left as if the work had never started. This all-or-nothing behavior is what lets a program move money between two accounts, or update several related tables, without risking a half-finished state.
Jim Gray’s 1981 paper “The Transaction Concept: Virtues and Limitations” crystallized the idea as a programming abstraction. Gray describes a transaction as a transformation of state that has the properties of atomicity (changes are all or nothing), durability (committed effects survive failures), and consistency (each transaction is a correct transformation of the state). Programmers declare transaction boundaries, and the database system handles the hard work of recovery and coordination underneath.
The power of the concept is that it hides enormous complexity behind a simple contract. Behind a commit, the system may be writing logs, holding locks, and coordinating with other processes, but the application only has to say “begin,” do its work, and “commit” or “abort.” Theo Haerder and Andreas Reuter’s 1983 survey built on this foundation, organizing the recovery and concurrency machinery that makes transactions reliable in practice.
Transactions are central to relational databases and to many systems beyond them. They give concurrent users the illusion that they each have the database to themselves, and they give applications a clean way to recover from crashes, making transactional storage one of the most durable abstractions in computing.