Properties of transactions

Transactions provide the ACID properties:

• Atomicity. The changes in a transaction are atomic: either all operations that are part of the transaction occur or none occurs.
• Consistency. A transaction moves data between consistent states.
• Isolation. Even though transactions can be run concurrently, no transaction sees another transaction's work in progress. The transactions seem to run serially.
• Durability. After a transaction completes successfully, its changes survive subsequent failures.

For example, consider a transaction that transfers money from one account to another. In such a transfer, money is removed from one account and put into the other. These actions are two parts of an atomic transaction; that is, if both cannot be completed, neither must happen. If multiple requests are processed against an account at the same time, they must be isolated so that only a single transaction can affect the account at one time. If the central computer of the bank fails just after the transfer, the correct balance must still be shown when the system becomes available again; that is, the change must be durable. Note that consistency is a function of the application; if money is to be transferred from one account to another, the application must subtract the same amount of money from one account that it adds to the other account.

Transactions can be completed in one of two ways: they can commit or abort. A successful transaction is said to commit. An unsuccessful transaction is said to abort. Any data modifications that are made by an aborted transaction must be undone (rolled back). In the preceding example, if money is removed from one account but a failure prevents the money from being put into the other account, any changes that are made to the first account must be undone. The next time that any source queries the account balance, the correct balance must be shown.