A transaction is a sequence of operations performed as a single logical unit of work. A logical unit of work must exhibit four properties, called the ACID (Atomicity, Consistency, Isolation, and Durability) properties, to qualify as a transaction:

 

Managing Transactions :

The repository engine permits nesting of Begin and Commit method invocations, but no actual transaction nesting occurs. A nested transaction count is maintained for each open repository instance.

Invoking the Begin method during an active transaction increments the nested transaction count by one, but has no other effect.

Invoking the Commit method during an active transaction decrements the nested transaction count by one. If, and only if, this decrement reduces the nested transaction count to zero, all updates are committed to the repository database.

Invoking the Abort method during an active transaction undoes all changes made during that transaction. Changes made during any nested transactions are also undone, even if the Commit method has already been invoked for those transactions. The nested transaction count is set to zero.

The repository engine changes are cached to improve performance. Guaranteed updates to a repository are written to persistent storage only when the active transaction is committed.

 

By default, multiple repository instances within the same process share a repository cache. Within the same process, when a transaction for one repository instance commits, its updates are immediately visible to transactions executing for other repository instances. These updates are not visible to open repository instances in other processes if those processes already have the preupdate data cached. Explicit refreshes are required to view updates from transactions that have completed in other processes.

 

You can override the default sharing behavior by setting a flag that allocates a new cache for each repository instance. For more information about REPOS_CONN_NEWCACHE, see ConnectionFlags Enumeration.

You can customize cache behavior by defining different age out strategies for different kinds of rows. For more information about age out strategies and caching behavior, see Optimizing Repository Performance.

To refresh a cache

• Refresh an individual repository item by invoking the Refresh method for the repository item.

This method invalidates unchanged cache data for the repository item. Subsequent requests for that data will be fulfilled by retrieving the data from the repository database.

-or-

• Refresh all repository items currently cached for an open repository instance by invoking the Refresh method associated with that repository instance.

This method invalidates unchanged cache data for all repository items. Subsequent requests for that data will be fulfilled by retrieving the data from the repository database.

In addition to explicit refreshes, repository items may be refreshed implicitly at any time by the repository engine, due to execution of internal repository caching algorithms

 

Integration with Distributed Transaction Coordinator : 

You can design an application that runs a distributed transaction on Microsoft® SQL Server 2000 running on Microsoft Windows® 2000.

Before you use Microsoft Distributed Transaction Coordinator (MS DTC) with a SQL Server 2000 Meta Data Services repository, you must install the Windows 2000 Service Pack 1. This service pack fixes an intermittent bug that causes MS DTC to stop responding when committing changes to a repository database.

The protocol for coordinating transaction atomicity across multiple resource managers is a two-phase commit. The Microsoft facility for a two-phase commit is MS DTC. You can enable distributed transactions to support the following scenarios:

• Create an application that updates data in two repositories within the same transaction.
• Create an application that updates data in a repository and in another database with the same transaction.
• Create an application that runs a Microsoft Transaction Server (MTS) to update a repository while running the application within the transaction that called it.
• Create an information model that aggregates a repository object class and updates another database within the aggregation wrapper. 

The distributed transaction must be atomic; that is, it must either commit at all resource managers or terminate at all of them. For more information about supporting atomic operations, see Transaction Management Overview.

The Transaction Protocol

To support MS DTC in your application, you must set the TXN_USE_DTC transaction flag. IRepositoryTransaction supports the TXN_USE_DTC flag on the GetOption and SetOption methods. The bit value for TXN_USE_DTC is 10. The default value of this option is FALSE. If the value is set to TRUE, each call to IRepositoryTransaction::Begin will create an MS DTC transaction. IRepositoryTransaction::SetOption(10, 1)                                           IRepositoryTransaction::Begin

MS DTC requires that the participant who started the transaction be the only party who can call Commit.

Programming in VC++

If you are a Microsoft Visual C++® programmer, you can use the ITransactionJoin::JoinTransaction method. You can use this method to cause a repository instance that is not currently running a transaction to become part of an existing MS DTC transaction. The active MS DTC transaction object is passed in as an input argument. For more information about the ITransactionJoin interface, see SQL Server Books Online.

Programming in Visual Basic

Microsoft Visual Basic® applications must use the following API to enlist an MS DTC transaction:

HRESULT IRepositoryTransaction2::JoinTransaction ([in]VARIANT sVArTxn);

where sVArTxn is an IUnknown pointer to the distributed transaction coordinator.

 

For more information ref. BOL