Atomicity： Suppose that， just before the execution of transaction Ti， the values of accounts A and B are $1000 and $2000， respectively. Now suppose that， during the execution of transaction Ti， a failure occurs that prevents Ti from completing its execution successfully. Further， suppose that the failure happened after the write（A） operation but before the write（B） operation. In this case， the values of accounts A and B reflected in the database are $950 and $2000. The system destroyed $50 as a result of this failure. In particular， we note that the sum A + B is no longer preserved.
　　Thus， because of the failure， the state of the system no longer reflects a real state of the world that the database is supposed to capture. We term such a state an inconsistent state. We must ensure that such inconsistencies are not visible in a database system. Note， however， that the system must at some point be in an inconsistent state. Even if transaction Ti is executed to completion， there exists a point at which the value of account A is $950 and the value of account B is $2000， which is clearly an inconsistent state. This state， however， is eventually replaced by the consistent state where the value of account A is $950， and the value of account B is $2050.Thus， if the transaction never started or was guaranteed to complete， such an inconsistent state would not be visible except during the execution of the transaction. That is the reason for the atomicity requirement： If the atomicity property is present， all actions of the transaction are reflected in the database， or none are.
　　The basic idea behind ensuring atomicity is this： The database system keeps track （on disk） of the old values of any data on which a transaction performs a write. This information is written to a file called the log. If the transaction does not complete its execution， the database system restores the old values from the log to make it appear as though the transaction never executed. Ensuring atomicity is the responsibility of the database system; specifically， it is handled by a component of the database called the recovery system， which we describe in detail in Section 12.7.
　　Durability： Once the execution of the transaction completes successfully， and the user who initiated the transaction has been notified that the transfer of funds has taken place， it must be the case that no system failure can result in a loss of data corresponding to this transfer of funds. The durability property guarantees that， once a transaction completes successfully， all the updates that it carried out on the database persist， even if there is a system failure
　　after the transaction completes execution.
　　We assume for now that a failure of the computer system may result in loss of data in main memory， but data written to disk are never lost. We can guarantee durability by ensuring that either：
　　1. The updates carried out by the transaction have been written to disk before the transaction completes.
　　2. Information about the updates carried out by the transaction is written to disk， and such information is sufficient to enable the database to reconstruct the updates when the database system is restarted after the failure.
　　……