You can be sure that some failures will happen in computer systems. Because this is a known fact, all software designers have to incorporate features to protect data when failures occur. They must protect against power failures, disk crashes, and the consequences of buggy code. As we've seen, Exchange uses an atomic transaction model to write data to the Store. Let's explore how that data is protected.

Figure 4.4: Transaction writes into the Store

As shown in Figure 4.4, Exchange uses a write-ahead logging mechanism to record transactions. Transactions applied to the Store databases always use a two-phase commit process. This method ensures that all changes made to the database that are part of a transaction must be performed before the transaction is committed. If a transaction is aborted, all updates relating to the transaction must be rolled back.

Information about the individual page modifications in the database that make up each transaction (for example, the delivery of a new message) is first recorded into the transaction log buffer. To ensure the integrity of the database, the original content of the pages that are modified during a transaction are actually held in a special memory area, called the version store. The version store gives ESE the ability to track and manage concurrent transactions by guaranteeing that a session will see a consistent image of the database during a transaction. In other words, a session executing a transaction sees the database as...