Because an operation may be interrupted by another thread or by a second user, there is no guarantee that any particular set of commands will complete before some other set begins. This can create significant challenges for the application programmer.
When I go to my bank and deposit that check you gave me at the poker game last night, I expect that the amount of the check (say, $100) will be deposited in my account. That is my contract with the bank — I make a deposit and the money winds up in my account. Your contract with the bank is such that your account winds up being debited the same $100. For checks to "work", both of these effects have to happen. If my account is credited and yours is not debited, the bank suffers. If your account is debited and mine is not credited, the bank is in danger of losing a customer.
In a well-designed system, there are only two possible outcomes: either both accounts are adjusted or nothing changes. The latter would be the case, for example, if your checking account had less than $100 and you had no overdraft protection.
The idea here, that either all of the changes (to the banking database) take place or none takes place at all, is the essence of a transaction. After all of the changes are made, the transaction is committed. If the transaction cannot commit, all of its changes to the database are rolled-back. The transaction is said to be aborted.
A transaction is a set of related operations, of which either all or none must be completed.
Committing is writing all the changes to the database at once.
Rollback, or abort, is undoing all the changes.
The following processing mechanisms are required to support multi-tasking and multi-user programs:
Checkpoint: a copy of the state of the database at a particular moment in time, which can be restored in case of failure