There are at least two levels of transactional consistency for replicated data in distributed applications:
With immediate transactional consistency (called tight consistency in Microsoft® SQL Server™ version 6.x), all participating sites are guaranteed to always see the exact same data values at the exact same time, and the data is in the state that would have been achieved had all the work been done at the publishing site. The only way for SQL Server to achieve transactional consistency in a distributed update environment (where updates can be made to the same data at any location) is with the use of a two-phase commit protocol between all participating sites. Each site must simultaneously commit every change, or no site can commit the change. Such a solution is obviously not feasible for large numbers of sites because of realities such as network outages.
With latent transactional consistency (called loose consistency in SQL Server 6.x), all participating sites are guaranteed to have the same data values that were achieved at the publishing site at some point in time. But there can be a delay in the data values being reflected at the participating sites, so that at any instant in time, the sites are not assured of having the exact same data values. If all data modification could be paused long enough to allow every site to catch up and have every change applied, then all sites would have the same data values. But just having the same value is not sufficient for latent transactional consistency. In addition, those values must also be the same as those that would have been achieved had all the work been done at one site. The difference between immediate and latent transactional consistency is whether the values are consistent at the same instant in time. If the system were allowed to quiesce, then the values would ultimately be identical no matter if the system is based on immediate or latent transactional consistency.
| Transaction Processing vs. Decision Support | Transactions |