Results of the transaction's execution are either all committed or all rolled back.
In Microsoft Exchange Server, atomic operations are achieved through the use of transaction logs. As mentioned earlier, transactions in the log that haven't yet been committed to the main database file are either rolled forward and committed, or are rolled back if incomplete. This process happens quickly and automatically when the system is restarted.
A shared resource (such as a database) is always transformed from one valid state to another valid state. All operations on the Microsoft Exchange Server information store are atomic, and ensure that the data is always in a consistent state. Updating a transaction log to indicate that a transaction has been completely committed back to the main database file is an atomic operation.
Transactions are recorded in a serial fashion in a system handling multiple simultaneous transactions. The result of any transaction is the same as if it were the only transaction running on the system. This implies that safe, concurrent access to the data by multiple simultaneous users occurs. Simultaneous user operations cannot interfere with each other in a way that renders the database invalid. The isolation property is enforced by the database underlying the Microsoft Exchange Server information store.
The results of a transaction are permanent and survive future system and media failures. Microsoft Exchange Server transaction logs implement the principle of durability. If, for example, a portion of a log file is corrupt or unreadable due to physical drive damage, those transactions are rolled back.
Even with media damage, the physical format of transaction logs is carefully designed to reduce the impact of any media failure, through a combination of sequential writes, the creation of new log files every 5 MB, and low-level techniques logging. This last technique maximizes the durability of transactions, even within a partially corrupted log file.
Concern has been expressed that using transaction logs can incur significant overhead because the data must be written more than once (first to the log, then to the main database file). However, the correct use of transaction logs actually improves overall system throughput, for a number of reasons.
When transaction log files are stored on a separate disk, they are written sequentially, rather than through random access. Because the disk drive head doesn't have to seek randomly, the process is faster than random-access writes to the main database file (even with today's fast hard drive subsystems). The transaction log files are then "lazily" committed back to the main database file. (Lazy commit is similar to lazy write, which is the ability to record changes in the file structure cache, which is quicker than recording them on disk, and then later, when demand on the computer's central processing unit (CPU) is low, the Cache Manager writes the changes to the disk.) This can be accomplished efficiently for the following reasons:
In addition, Microsoft Exchange Server recovery techniques work as well for large records as they do for small ones. This is because the transaction logs are smart enough to write only the data that has actually changed. Therefore, if a user changes only a few bytes of a 2-MB document stored in a Microsoft Exchange Server computer, only the actual data pages that are changed are written to the log.