Storage Objects and Rowset Update Semantics
When does the data that is set in a storage object become visible to other transactions operating at the Read Uncommitted transaction isolation level? For providers built over database servers, this question can also be phrased as, "When does data that is set in a storage object become visible in the data store?"
The rules for storage objects are similar to the rules for data in other columns. That is, if the rowset is in immediate update mode, data made available to the rowset is immediately made available to Read Uncommitted transactions. If the rowset is in deferred update mode, data made available to the rowset is not made available to Read Uncommitted transactions until the consumer calls IRowsetUpdate::Update.
However, storage objects differ in two ways from other, nonstorage columns in the rowset:
Storage mode?Storage objects can have another layer of buffering based on the storage mode in which they operate. If the storage object operates in transacted mode, data is not available to the rowset until the consumer calls ITransaction::Commit on the storage interface. If the storage object operates in direct mode, data is immediately available to the rowset when the consumer sets it in the storage object.
**Ignore deferred update mode?**Storage objects can be large. Therefore, using them in deferred update mode can be expensive because the provider may locally cache any changes to them until IRowsetUpdate::Update is called. Consumers need to control this expense, so the DBPROP_DELAYSTORAGEOBJECTS property controls whether storage objects are always in immediate update mode, whether or not the rowset is in immediate or deferred update mode. For some providers, this is a read-only property. See the following illustration.
Storage object update visibility
.gif "visibility of storage objects during updates")
The following table shows the sequence of calls needed to make data that is set in a storage object visible to other transactions operating at the Read Uncommitted isolation level. In this table, Write refers collectively to any method on a storage interface that sets data, such as ISequentialStream::Write, IStream::Write, or ILockBytes::WriteAt, and SetData refers collectively to IRowsetChange::SetData and IRowsetChange::InsertRow. ILockBytes storage objects are always in Direct mode.
Storage mode |
Update mode |
DBPROP_DELAYSTORAGEOBJECTS |
Calls needed to expose data to other transactions running at Read Uncommitted |
|---|---|---|---|
Direct |
Immediate |
Not applicable |
Write ? or ? SetData |
Direct |
Deferred |
VARIANT_FALSE |
Write ? or ? SetData |
Direct |
Deferred |
VARIANT_TRUE |
Write Update ? or ? SetDataUpdate |
Transacted |
Immediate |
Not applicable |
Write Commit on storage interface ? or ? SetData |
Transacted |
Deferred |
VARIANT_FALSE |
Write Commit on storage interface ? or ? SetData |
Transacted |
Deferred |
VARIANT_TRUE |
Write Commit on storage interfaceUpdate ? or ? SetDataUpdate |
When the rowset is in deferred update mode, the consumer cannot undo any pending changes made through a storage object that is still open. That is, if the provider creates a storage object over the BLOB and returns a pointer to it through IRowset::GetData, the consumer must release this storage object before calling IRowsetUpdate::Undo. If the consumer fails to release the storage object, Undo returns a status of DBROWSTATUS_E_OBJECTOPEN for the row.
This topic is a part of: