Transaction should commit as whole or should rollback as whole. A transaction should possess following properties
1) Atomicity refers to the ability of the DBMS to guarantee that either all of the tasks of a transaction are performed or none of them are. The transfer of funds can be completed or it can fail for a multitude of reasons but atomicity guarantees that one account won't be debited if the other is not credited as well. 2) Consistency refers to the database being in a legal state when the transaction begins and when it ends. This means that a transaction can't break the rules or integrity constraints of the database. If an integrity constraint states that all accounts must have a positive balance then any transaction violating this rule will be aborted. 3) Isolation refers to the ability of the application to make operations in a transaction appear isolated from all other operations. This means that no operation outside the transaction can ever see the data in an intermediate state; a bank manager can see the transferred funds on one account or the other but never on both even if she ran her query while the transfer was still being processed. More formally isolation means the transaction history (or schedule) is serializable. For performance reasons this ability is the most often relaxed constraint. See the isolation article for more details. 4) Durability refers to the guarantee that once the user has been notified of success the transaction will persist and not be undone. This means it will survive system failure and that the database system has checked the integrity constraints and won't need to abort the transaction. Typically all transactions are written into a log that can be played back to recreate the system to its state right before the failure. A transaction can only be deemed committed after it is safely in the log.
