Storage Objects and Transactions
Whether storage objects are transacted depends on the DBPROP_TRANSACTEDOBJECT property, which can be set on a per-column basis. If the value of this property is VARIANT_TRUE, any storage object that was created on the column is transacted. That is, when a consumer calls ITransaction::Commit and the provider commits all data visible to the rowset, this includes data made visible to the rowset through storage objects. When a consumer calls ITransaction::Abort and the provider rolls back all data visible to the rowset, this includes data made visible to the rowset through storage objects. For information about what data in storage objects is visible to the rowset, see Storage Objects and Rowset Update Semantics.
Whether uncommitted data in transacted storage objects remains valid and whether the storage objects themselves remain valid when the transaction is committed or aborted depend on the retaining flag (fRetaining) used in the call to ITransaction::Commit or ITransaction::Abort. The retaining flag set to TRUE implicitly starts a new unit of work. If a commit is retaining, the storage objects and any uncommitted data in them remain valid. If an abort is retaining, the storage objects remain valid but any uncommitted data in them is lost; moreover, the provider must synchronize the object with its state in the data store after the transaction was aborted there. If the rowset is not preserved after a commit or abort, the storage objects enter zombie states and any uncommitted data in them is lost. The consumer can only call Release on such objects. All other methods return E_UNEXPECTED. Whether the rowset is preserved depends on the DBPROP_COMMITPRESERVE and DBPROP_ABORTPRESERVE properties. For more information about committing and aborting a transaction, see ITransactionObject.
If the value of DBPROP_TRANSACTEDOBJECT is VARIANT_FALSE, any storage object that was created on the column is not transacted. That is, all changes to the storage object are permanent after they are made visible in the data store. Calling ITransaction::Commit or ITransaction::Abort on a session containing a rowset with nontransacted storage objects should not affect the state of the storage object.
This topic is a part of: