. Net remoting transaction propagation and WCF Distributed Transaction

In. NET 1.1 or. to implement distributed transactions in net 2.0, if remote calls are not involved, such as calling remoting or web service methods, it should be said that it is a very simple thing, you only need to use COM + (1.1/servicedomain) or transactionscope (2.0) and use MSDTC for coordination.

However, when remoting or Web Service (WS-at is not used) needs to be called in the transaction method, because remoting does not support the transaction propagation mechanism, even if an error rollback occurs after the client calls remoting, operations (such as database operations) performed on the remoting server cannot be rolled back.

However, in some special applications where data integrity is more important than performance, the operations executed on the remoting server can also be rolled back if you want the client to roll back, you can use MSDTC's transaction Internet Protocol (TIP) Protocol (in fact, MSDTC supports both common oletx distributed transaction protocols and Xa and tip protocols ), let the transaction started by the client "spread" to the remoting server, so that as long as the remoting server uses the transaction transmitted by the client, the distributed transaction under remoting can be implemented. The procedure is as follows:
(1) because the tip transaction protocol is disabled by default, the first step is to configure MSDTC to support tip transactions. On the MSDTC properties page, click "Security Configuration" and select "enable tip transaction ".
(2) implements the itiptransaction interface to query the related attributes of tiptransaction from contextutil. transaction. Obtain the tip URL attribute of the tip transaction.

Definition of the itiptransaction interface: [GUID ( " 17cf72d0-bac5-11d1-b1bf-00c04fc2f3ef " )]
[Interfacetype (cominterfacetype. interfaceisiunknown)]
Public   Interface Itiptransaction
{
Void Push ([IN, financialas (unmanagedtype. lpstr)] String Pszremotetmurl,
[In, out, financialas (unmanagedtype. lpstr)] Ref   String Ppszremotetxurl );

Void Gettransactionurl ([In, out, financialas (unmanagedtype. lpstr)]
Ref   String Ppszlocaltxurl );
}  

Obtain the tip URL Code : String URL =   Null ;

Itiptransaction trxn = (Itiptransaction) contextutil. transaction;

Trxn. gettransactionurl ( Ref URL );

(3) Pass the obtained tip URL to the remoting server through a certain mechanism.
There are many methods to pass the tip URL to the remoting server. You can pass it through parameters or callcontext. For details, refer to the attachment code.

(4) In the remoting server, use the tip URL to connect to the client transaction and start the transaction.
After obtaining the tip URL passed by the client, you can use it to connect to the existing Transaction Coordinator. The Code is as follows: Transactioncallcontext CTX = (Transactioncallcontext) callcontext. getdata ( " Dtctxid " );
Serviceconfig config =   New Serviceconfig ();

If (CTX ! =   Null )
{
Config. tipurl=CTX. tipurl;
Config. Transaction=Transactionoption. requiresnew;
}
Else
{
Config. Transaction=Transactionoption. Disabled;
}

Using (Transactionscope scope Scope =   New Transactionscope (config ))
{
Rows = Updatepoint ();

If (Rows >   0 )
{
Scope. setcomplete ();
}
}

With the above method, you can implement distributed transactions under remoting.

Source code:
/Files/walkinhill/remotingtransactiondemo.rar

ReferenceArticle:
Http://dotnetjunkies.com/WebLog/chris.taylor/articles/54503.aspx
Http://www.codeproject.com/csharp/complus_tip.asp

Although the distributed transactions under remoting are implemented through the above method, it is still a little troublesome, and an error may occur accidentally. In contrast, WCF has implemented such a transaction mechanism internally, and only needs to be configured and added with some features. It also supports oletransactions and WS-at protocols. It seems that it will be much more convenient to use WCF later.

At last, I only learned about the distributed transactions under remoting, but I still need to fully consider the performance. After all, remote calls consume a lot of performance, especially the lock on resources in transactions causes more serious performance degradation :)