In their simplest form, both snapshot and transactional replication are based on a model of one-way replication; that is, data is replicated from a Publisher to a Subscriber. However, Microsoft® SQL Server™ builds additional functionality into this model by allowing Subscribers to modify replicated data as well. The Immediate-updating Subscribers option provides latent transactional consistency to other Subscribers (it is immediate between the Subscriber doing the updating and the Publisher) without requiring that updates only be done at the publishing site. This option is set at the time the publication is created and allows a Subscriber to update the copy of its local data, as long as that update can be immediately reflected to the Publisher by using the two-phase commit protocol (2PC). The 2PC protocol is managed by the Microsoft Distributed Transaction Coordinator (MS DTC). If the update can be performed using 2PC, then the Publisher propagates those changes to all other Subscribers according to the Distribution Agent schedule (or at the time of the next snapshot refresh if it is a snapshot publication). Because the Subscriber making the update already has the data changes reflected locally, the user can continue working with the updated data secure in the guarantee that the Publisher data also reflects the change. There is no loss of transactional integrity.
Site autonomy is somewhat reduced with this option because the Publisher and the specific Subscriber making the change must both be available and networked at the same time. But autonomy is still much higher than if all Subscribers needed to accept the change immediately (as would be required for immediate transactional consistency). It may still be a good choice for connected nodes that need “master documents” like price lists or customer lists, which tend not to have very high update rates and do not need to be immediately propagated to all other nodes.
When a publication is enabled to support the Immediate-updating Subscribers option, a Subscriber can modify replicated data if the transaction can be performed by using the two-phase commit protocol (2PC) with the Publisher. This approach provides latent transactional consistency to other Subscribers without requiring that updates only be done at the publishing site. The 2PC transaction back to the Publisher is done automatically, so an application can be written as though it is updating just one site. This approach does not have the availability constraint of doing 2PC to all participating sites, because only the Publisher needs to be available. After the change is made at the Publisher under 2PC, it will eventually get published to all other Subscribers to the publication, thereby maintaining latent transactional consistency.
This capability avoids requiring that applications be written to perform data modification operations at the Publisher and read operations at the Subscriber. The application works with data at one site, and the 2PC transaction is performed automatically. The application should be equipped to deal with a failure in the transaction, just as it would in a nonreplication environment. The most common failure is that data has been changed at the Publisher and Subscribers need to refresh their copies. If the transaction is successful, the Subscriber can immediately work with the changed values, and know that the update has been accepted at the Publisher without conflict and will eventually be replicated to every subscription of the publication. A Subscriber performing updates does not have full autonomy, however, because the Publisher must be available at the time of the update. But autonomy is much higher than the full 2PC case where every site must be available for any site to perform changes.