Immediate vs. Deferred Update Mode
Whether the consumer uses immediate or deferred update mode depends on how many consumers share the rowset and how they use the rowset. In most cases, the primary user of immediate update mode is a single consumer that wants to transmit changes immediately to the data store. Consumers use deferred update mode for many reasons, including the following:
Shared rowsets ? If multiple consumers share a rowset, they often use notifications to coordinate multiple changes. By using deferred update mode, consumers can coordinate their changes locally in the rowset before transmitting them to the data store.
Multiple changes to the same row ? If a consumer makes multiple changes to the same row, such as when multiple accessors are used or when users input changes at different times, the row might be left in an invalid state. For example, if a key consists of several columns and each column is changed in a separate call to IRowsetChange::SetData, the intermediate states might be invalid. By using deferred update mode, the consumer can buffer these changes in the rowset before transmitting them to the data store.
Network traffic ? If a rowset resides on one node in a network and the data store resides on another node, transmitting changes from the rowset to the data store requires a network call. By using deferred update mode, the consumer can batch changes to multiple rows and send them across the network with a single call to IRowsetUpdate::Update. This is particularly critical for wide area networks such as the Internet, on which network calls are very expensive.
Undoing changes ? IRowsetUpdate::Undo enables the consumer to undo pending changes. By using deferred update mode, consumers can expose an undo capability to users without having to implement it.
This topic is a part of: