Udostępnij za pośrednictwem


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

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: