Florin Lazar - Consistency Checkpoint

System.Transactions and Allow Inbound/Outbound DTC Settings

florinlazar — Thu, 24 Sep 2009 08:27:00 GMT

If you do distributed transactions across the network, you know about Allow Inbound and Allow Outbound security settings for DTC (available by running dcomcnfg or by opening Component Services). The help describes these settings as: Allow Inbound...(read more)

Intro for Microsoft Azure .Net Service Bus

florinlazar — Fri, 03 Apr 2009 05:10:00 GMT

Clemens Vasters gives a great introduction to Microsoft Azure .Net Service Bus and its 4 feature areas: Naming, Registry, Connectivity, and Eventing. Find it at http://vasters.com/clemensv/PermaLink,guid,92d78bee-2cfd-4a29-95ab-c5abb9b905e7.aspx...(read more)

Atbroker.exe application error - CTRL-ALT-END in a remote session

florinlazar — Wed, 26 Nov 2008 04:20:00 GMT

I use remote desktop daily. The Atbroker.exe application error followed by black screen seemed to be gone for a while. Now it is back. The only solution that I know of and which works most of the times is "CTRL-ALT-END" (the equivalent of “CTRL-ALT-DEL...(read more)

When not to use transactions and where you can't use transactions

florinlazar — Fri, 09 May 2008 01:21:00 GMT

Transactions are great when everyone plays in. You group a set of activities together under a transaction and you start executing them. If anything bad happens along the way or something doesn't go as planned, invoke rollback and all is taking care of...(read more)

MSDTC and COM+ Configuration Tool in Vista

florinlazar — Thu, 08 May 2008 01:01:00 GMT

To access the MSDTC and COM+ configuration tool in Windows Vista, also known as Component Services MMC, you have the following options: 1. Run “dcomcnfg” 2. Or run: %SystemRoot%\System32\comexp.msc 3. Or if you prefer, you can add a shortcut...(read more)

Exception Handling without catch(Exception)

florinlazar — Wed, 07 May 2008 09:58:00 GMT

The design guidelines for exception handling are quite clear on avoiding “catch all” and/or avoiding catching exceptions you can’t handle. But there are cases when you really need to know if the try block completed successfully or not, and possibly take...(read more)

Working with CMD and Long Path Names

florinlazar — Tue, 06 May 2008 22:54:00 GMT

I like using the command prompt for a lot of things and working with long (or very long) path names is something that is common these days. Fortunately, you can customize cmd by using "prompt". Do a “prompt /?” in a command window to see all the options...(read more)

How to Use System.Data with System.Transactions and Maintain Atomicity and Data Consistency

florinlazar — Mon, 05 May 2008 13:04:00 GMT

The Bug I call it a bug. Initially I was persuaded to believe it was a feature; later I was "convinced" that it is now a matter of app compat and it can't be changed anymore. Let’s look at the following code: SqlConnection connection1 ...(read more)

Limitation of TransactionScope (and using)

florinlazar — Mon, 05 May 2008 11:38:00 GMT

If you read the documentation for TransactionScope , you will find: "If no exception occurs within the transaction scope […], then the transaction in which the scope participates is allowed to proceed. If an exception does occur within the transaction...(read more)

Avoiding Transaction Promotion with Multiple Connections - Improvements in System.Data and SQL Server 2008

florinlazar — Sat, 03 May 2008 02:02:00 GMT

Great news! The new updates added to System.Data and SQL Server 2008 finally allow multiple Open/Close connections to the same SQL Server without promoting the transaction to MSDTC. This was by far the most requested feature for the System.Transactions...(read more)

A Simpler TransactionScope

florinlazar — Mon, 24 Mar 2008 22:33:00 GMT

In .Net 3.5 I can write a transactional code block as follows: transacted(()=> { using (SqlConnection connection = new SqlConnection(connectionString)) { connection.Open(); SqlCommand command1 = new SqlCommand(commandString1, connection...(read more)

Flowing or propagating transactions in .Net

florinlazar — Wed, 20 Feb 2008 21:36:00 GMT

System.Transactions transactions are bounded to the appdomain. Which means that if you make in-appdomain calls from inside a TransactionScope, those calls will share the transaction. This also means that if you need to make a call outside the current appdomain, or outside the process, you will need to "flow" the transaction.

To flow a System.Transactions transaction, there are a few options:

a. if you are using serialization

//sender code
using(TransactionScope ts = new TransactionScope())
{
  RemoteCallUsingSerialization(Transaction.Current, other parameter); // this is the call to other appdomain/process
  // notice I added a new parameter of type System.Transactions.Transaction  

  ts.Complete();
}

//destination code
void RemoteCallUsingSerialization(System.Transactions.Transaction tx, other parameter)
{
  using(TransactionScope ts2 = new TransactionsScope(tx))
  {
   // access transactional resourses like a database; this code will execute as part of the same transaction
   ts2.Complete();
  }
}

b. if you are not using serialization

//sender code
using(TransactionScope ts = new TransactionScope())
{  
  RemoteCall(TransactionInterop.GetTransmitterPropagationToken(Transaction.Current), other parameter); // this is the remote call
  // notice I added a new parameter of type byte[]  

  ts.Complete();
}

//destination code
void RemoteCall(byte[] tx, other parameter)
{
  using(TransactionScope ts2 = new TransactionsScope(TransactionInterop.GetTransactionFromTransmitterPropagationToken(tx)))
  {
   // access transactional resourses like a database;
   // this code will execute as part of the same transaction
   ts2.Complete();
  }
}

c. if .Net 3.0 or higher is an option, you can use WCF and its support for transactions using attributes: http://msdn2.microsoft.com/en-us/library/aa347993.aspx

Remark: When the transaction is flown outside the current appdomain, it will get upgraded to a distributed transaction (or MSDTC transaction).

If you are not using .Net, see http://blogs.msdn.com/florinlazar/archive/2004/10/02/236965.aspx for propagating transactions in C++.

TIP is now deprecated

florinlazar — Wed, 23 Jan 2008 04:10:00 GMT

TIP is getting deprecated - see the note at http://msdn2.microsoft.com/en-us/library/ms679484(VS.85).aspx
If the native OleTx protocol used by MSDTC and System.Transactions is not friendly enough for your firewall, you should consider the WS-AtomicTransactions protocol provided through Windows Communication Foundation in .Net Framework 3.0 and higher: http://msdn2.microsoft.com/en-us/library/ms730266.aspx

MSDN Magazine Article on Transactional File System

florinlazar — Wed, 11 Jul 2007 21:25:00 GMT

Jason Olson describes the Transactional NTFS and how you can take advantage of it in your applications: http://msdn.microsoft.com/msdnmag/issues/07/07/NTFS/default.aspx

WCF in Romania

florinlazar — Thu, 03 May 2007 09:27:00 GMT

These days I'm in Romania with a tour at 3 universities (in Bucharest, Cluj and Iasi) talking about Windows Communication Foundation, distributed systems and web services. Adi Oltean is also talking about storage technologies in Windows.

So far the seminars were received really well and we made a lot of friends. I'm really pleased to be able to contribute to the adoption of WCF and to demonstrate the amazing value and power of WCF with its productivity, interoperability and extensibility features.

More details at http://reg.studentclub.ro/RegisterForEvent.aspx?idEveniment=55 (in romanian).

I would like to thank Todi Pruteanu for organizing these events.

"Orcas" March 07 CTP: Support for OASIS WS-AT 1.1 and WS-Coord 1.1

florinlazar — Thu, 08 Mar 2007 03:58:00 GMT

In the "Orcas" March 2007 CTP for Visual Studio and .Net, Windows Communication Foundation brings support for OASIS specifications WS-AtomicTransaction 1.1 and WS-Coordination 1.1. WCF will have side-by-side support with the 1.0 versions of these specs.

To use the new version of WS-AT, you can specify the new WS2007HttpBinding, or, if you already use the NetTcpBinding, you can set the TransactionProtocol to WSAtomicTransactions11.

Allowing Transactions into Your Component: "Do you really want that?"

florinlazar — Wed, 07 Mar 2007 15:00:00 GMT

Supporting transactions is part of your component contract. If you shipped a component yesterday that exposed MyComp.DoWork to the public, and today you want to add transactional support to your component, you shouldn't use the same method MyComp.DoWork and make it transactions aware. Not unless you want to break your customers (see http://blogs.msdn.com/florinlazar/archive/2005/04/19/409834.aspx for details on how you can break existing apps). Instead you should publish a new method, MyComp.TransactedDoWork, that you document it as being transactions aware, i.e. it will participate in the ambient transaction if one is available.

The purpose of this post is not about TransactedDoWork, but rather about a new method, MyComp.DoMoreWork, that you want to add to your v2. Let's assume that in this method, you write an entry into a file, call a webservice and update two databases. Since you learned about System.Transactions, you are using TransactionScope to make the updates to the two databases. And since most of the samples use the default constructor for TransactionScope, you are probably doing it the same way:

using (TransactionScope ts = new TransactionScope())
{
    // open connection to db1
    // update db1
    // close connection to db1
    // open connection to db2
    // update db2
    // close connection to db2
    
    ts.Complete();
}

All appears to be good and so you ship MyComp v2. After a while, you start getting reports from your customers saying that sometimes, MyComp.DoMoreWork doesn't work properly: they see the update to the file, they see the webservice being called but the updates to databases are missing. What is going on?

Well, the default constructor for TransactionScope uses TransactionScopeOption.Required, which enlists in the ambient transaction if one exists. Thus, if your customers are using transactions and they call MyComp.DoMoreWork, and if the transaction aborts, part of the work done by DoMoreWork is going to be rollbacked!! But that wasn't what you intended.

The best practice is to always "protect" your outermost TransactionScopes in our component from enlisting in the ambient transaction by using a non-default constructor, TransactionScope(TransactionScopeOption.RequiresNew) or TransactionScope(TransactionScopeOption.Suppress), depending on your particular scenario. Of course, if you want the transaction to flow inside the component you can use the default constructor, but that should be a conscious decision.

Given that the TransactionScope is usually hidden into the call stack of your component method, for instance:

void MyComp.DoMoreWork
{
    internalDoTheRealMoreWork(); // the first TransactionScope shows up inside internalDoTheRealMoreWork
}

The best way to deal with unwanted transactions is to start your public interface methods with a non-default TransactionScope:

void MyComp.DoMoreWork
{
    using (TransactionScope ts = new TransactionScope(TransactionScopeOption.Suppress))
    {
        internalDoTheRealMoreWork();		
        ts.Complete();
    }
}

The reason why TransactionScope default is Required is to allow easy creation of imbricated or nested TransactionScopes (not to be confused with "nested transactions"):

void internalDoTheRealMoreWork()
{
    using (TransactionScope ts = new TransactionScope())
    {
        // work
        myOtherInternalWork();
        ts.Complete();
    }
}
void myOtherInternalWork();
{
    using (TransactionScope ts = new TransactionScope())
    {
        // do other work
        ts.Complete();
    }	
}

With the default constructor you write less code and the transactions "flows" nicely from method to method in the call stack. You are supposed to use the non-default constructors for TransactionScope, when you want to make a decision not to allow the ambient transaction inside your component or method. One of those cases is in the public interface methods.

Next time you write a public method, always ask yourself - "do I want to let a transaction in or not?" - if the answer is no, then start your public method with a non-default TransactionScope. And remember to document your method's behavior with regards to transactions.

Supporting Promotable Transactions and Phase 0

florinlazar — Sat, 10 Feb 2007 16:48:00 GMT

If you are providing support for promotable transactions for your resource manager using PSPE then you need to remember to "support" Phase 0.

In general, a resource manager doesn't need to do anything special about Phase 0; this phase will be handled solely by the transaction manager. But, because in the case of promotable transactions using the PSPE mechanism, the resource manager acts as a special "transaction manager", your resource manager needs to be aware of Phase 0. Why? Because in this case, the resource manager "owns" the distributed transaction and System.Transaction will call Commit on the PSPE interface asking the resource manager to call Commit on the distributed transaction. The resource manager needs to be aware that even after it will call Commit on the distributed transaction it owns, there is a possibility that requests to enlist and do work as part of the same transaction are still possible, based on the Phase 0 rules. And these requests are supposed to be accepted. Don't worry, there will be no data corruption. MSDTC guarantees that Phase 0 happens before Phase 1 starts delivering its "prepare" messages.

What exactly you need to do to ensure Phase 0 support? Let's create the list:

when you receive the "commit" request through the PSPE interface, call Commit on the distributed transaction but do not start the commit process on your data yet; wait for the Prepare message on the distributed transaction from MSDTC before doing any work (this assumes you are enlisted with that transaction - you should be!); in other words, when you receive the IPromotableSinglePhaseNotification::SinglePhaseCommit simply "pass" along the Commit to the distributed trasaction you own and don't do anything else
don't get confused by the name of IPromotableSinglePhaseNotification::SinglePhaseCommit; it is not the same as the classic single phase commit from MSDTC; there might be phase 0 enlistments out there that might enlist other durable resource managers in the transaction, and thus a 2-Phase-Commit might be necessary
even after calling Commit on the distributed transaction, you should continue to accept new connections and work on the same transaction; don't worry, phase 1 didn't start yet, these are just phase 0 enlistments "flushing" their data to durable stores
once you received the "prepare" message from MSDTC on the distributed transaction, only then you should start your normal 2PC operation
if any new request is received on the same transaction after "prepare" was received from MSDTC, you should deny it as you do in any 2PC scenario after phase 1 started

Sounds like a lot of steps, but in reality, this can be said in a short summary: "when you receive IPromotableSinglePhaseNotification::SinglePhaseCommit, pass along the Commit to the distributed transaction you own and behave like it didn't happen :), i.e. accept new connection requests in the same transaction until MSDTC delivers you the "prepare" message.

Of course, if Promote was never called, then there isn't any distributed transaction involved and thus you can proceed with commiting the work when IPromotableSinglePhaseNotification::SinglePhaseCommit is called.

Thanks for supporting promotable transactions and Phase 0.

When transaction promotion goes "bad"

florinlazar — Thu, 08 Feb 2007 14:41:00 GMT

We already know the benefits of promotable transactions. They are all about performance, being very fast and lightweight.

But then you get into situations where you know for sure that you are going to talk to a second resource manager, so you know you will get to a distributed transaction anyway. Or, the resource managers out there that support promotable transactions might have limitations when you put them into edge cases. But you really want to use that edge case and it doesn't work.

Well, one solution is to "turn off" promotion and force a distributed transaction from the beginning such that all the resource managers involved will follow the classic route of enlisting in the transaction. We don't actually provide a flag today in System.Transactions to "turn off" promotable transactions, but you can achieve it by forcing the transaction to be a distributed transaction before you open any resource manager connection.

The way you do it in code is by calling:

TransactionInterop.GetTransmitterPropagationToken(tx);

Where tx is the transaction you want to promote.

If you are using TrasactionScope similar to:

using(TransactionScope ts = new TransactionScope())
{
    connection.Open();
    // do the work on the first connection
    connection2.Open();
    // do the rest of the work
    ts.Complete();
}

Then the code with the workaround should be:

using(TransactionScope ts = new TransactionScope();)
{
    TransactionInterop.GetTransmitterPropagationToken(Transaction.Current);
    connection.Open();
    // do the work on the first connection
    connection2.Open();
    // do the rest of the work
    ts.Complete();
}

With time, resource managers will get better. But today, you might find this <trick> useful.

Comments for 90 days only

florinlazar — Wed, 04 Oct 2006 04:39:00 GMT

I'm getting way too much spam these days. I wanted to keep the comments open for ever so I can get your feedback at any time you wanted to send it to me. Unfortunately spam is consuming my time so I decided to limit the lifetime for comments to 90 days starting from the day of the post.

If you want to send me feedback, you can use http://blogs.msdn.com/florinlazar/contact.aspx

If you have a question related to transactions, you can post it to our transactions forum at http://forums.microsoft.com/MSDN/ShowForum.aspx?ForumID=388&SiteID=1 where I'm the moderator.

Thanks for your understanding.

Phase0 in .Net System.Transactions

florinlazar — Sun, 09 Apr 2006 23:20:00 GMT

In a previous post (http://blogs.msdn.com/florinlazar/archive/2006/01/29/518956.aspx) I talked about Phase0 and some useful things it allows you to do. Although not referred as Phase0, phase 0 features are available in .Net System.Transactions in two forms. Actually in three, but the third is a derivate. I will make many references here to the previous post on Phase0 and thus I recommend reading it first.

The first form where Phase 0 shows up is through EnlistmentOptions.EnlistDuringPrepareRequired that you can pass to EnlistVolatile or EnlistDurable methods. This allows you to create new enlistments during Prepare phase (and after Commit was called) and thus it allows you to create the caching resource manager (RM) discussed in the earlier post. To create a cache RM, you will first call EnlistVolatile with EnlistmentOptions.EnlistDuringPrepareRequired, and then, during Prepare you will connect to the database to write the updates. The connection to the database will usually call EnlistDurable on the transaction. Similar to Phase0 in the native DTC API, during the Prepare phase, one can enlist again passing EnlistmentOptions.EnlistDuringPrepareRequired which will issue another round of Prepare on that enlistment and so on.

The second form comes with DependentTransaction. You get a DependentTransaction by calling the DependentClone method on a transaction object. You can get the other two scenarios enabled by Phase0, “early commit protection” and “async programming” by tweaking the DependentCloneOption to RollbackIfNotComplete and BlockCommitUntilComplete respectively. Then, you signal that the work is done by calling the Complete method of this dependent transaction.

Thus you will write the DoTransfer method in .Net as follows:

int DoTransfer(int amount, Transaction tx)
{
    // create the dependent clone
    DependentTransaction dtx = tx.DependentClone(DependentCloneOption. RollbackIfNotComplete);
    DB1.OpenConnection(tx);
    DB1.DoDebit(amount);
    DB2.OpenConnection(tx);
    DB2.DoCredit(amount);

// signal work complete on the “phase0” enlistment
dtx.Complete();
}

If the DependentTransaction is not Complete-ed before a Commit is issued by the client, the transaction will be aborted.

The “third” derivate form is TransactionScope itself. TransactionScope protects you against early commits by automatically handling under the covers a DependentTransaction with RollbackIfNotComplete. That is why TransactionScope is recommended for most of the transactions scenarios. Given this you can write with the same confidence the DoTransfer method as follows:

int DoTransfer(int amount, Transaction tx)
{
    // creating a TransactionScope by passing in the received transaction
    // this will set tx to be the ambient transaction and create a "rollback" dependent transaction
   using(TransactionScope ts = new TransactionScope(tx))
   {
       DB1.OpenConnection(); // note that now OpenConnection is picking the transaction from the ambient context instead of passing it as a parameter
       DB1.DoDebit(amount);
       DB2.OpenConnection();
       DB2.DoCredit(amount);

       ts.Complete();
   }
}

Other Scenarios enabled and/or made easier by DependentTransaction

The “Worker Threads Scenario”
This is explained both at http://pluralsight.com/blogs/jimjohn/archive/2005/05/01/7923.aspx and http://msdn2.microsoft.com/en-US/library/ms229976(VS.80).aspx

Passing transaction ownership in a sequence of threads
Described at http://pluralsight.com/blogs/jimjohn/archive/2006/01/01/17769.aspx.

Async Programming
This is the scenario described in my previous post where the client asks asynchronously a service to do some work as part of the transaction, but doesn’t want/need to wait until the service completes the work. The code will look like the following in .Net:

Client Code
void MainFunction()
{
    using(TransactionScope ts = new TransactionScope())
    {
        // dtx is a member of the current class of type DependentTransaction
        // its lifetime needs to be at least until the ack from the service is received
        this.dtx = Transaction.Current.DependentClone(DependentCloneOption.BlockCommitUntilComplete);
        AsyncDoTransfer(tx, AckFromDoTransfer);
        ts.Complete();
     }
}
void AckFromDoTransfer()
{
     this.dtx.Complete();
}

Server Code
void AsyncDoTransfer(tx, AckFromDoTransfer)
{
DependentTransaction dtx = tx.DependentClone(DependentCloneOption. BlockCommitUntilComplete);
AckFromDoTransfer(); // the client can Commit safely from now on since I have dtx created on the service side

    // the dependent clone auto-created by TransactionScope doesn’t help in this scenario because it rollbacks on early commit while we need a blocking clone
    using(TransactionScope ts = new TransactionScope(tx))
    {
        // doing the work that takes a lot of time
        DB1.OpenConnection();
        DB1.DoDebit(amount);
        DB2.OpenConnection();
        DB2.DoCredit(amount);
        ts.Complete();
    }

// work if finished on the service so we can safely let the transaction continue
dtx.Complete();
}

Our Own Forum is Now Live! Please Join Us at the "Transactions Programming Forum"

florinlazar — Sat, 11 Mar 2006 02:34:00 GMT

I'm really happy to announce that our own forum, dedicated to transactions in Windows and .Net is now live at http://forums.microsoft.com/MSDN/ShowForum.aspx?ForumID=388&SiteID=1

The RSS feed for the forum is http://forums.microsoft.com/MSDN/rss.aspx?ForumID=388&Mode=0&SiteID=1

I hope that by having a forum that is dedicated to Transactions technologies we can build a better channel for our customers to get quick and accurate answers to their questions. We encourage everyone in the community to participate in this forum.

I look forward to us working together to make this forum a valuable resource for Transactions discussions.

Dedicated Site for Transactions on Microsoft.com

florinlazar — Wed, 01 Mar 2006 13:01:00 GMT

In an effort to have a common place for all the transactions technologies we provide (and we started to have a good number of technologies that continues to grow), we have put together a webpage on Microsoft.com dedicated to transactions. The address is: http://www.microsoft.com/windowsserver2003/appserver/transmgmt.mspx

MSDTC: The Magic of Phase Zero (Phase0) – Or – When Using 2PC Transactions Is Not Enough

florinlazar — Mon, 30 Jan 2006 01:24:00 GMT

The most known technique of implementing distributed transaction is the "two-phase commit" (2PC). Here is a quick summary of how this technique works:
   - Active phase: After the transaction is created and before the "commit" message is issued by the creator, the transaction is in the "active" state. During this phase, resource managers can "enlist" and become part of the transaction. When "commit" is issued, the transaction moves to Phase1.
   - Phase1 (preparing phase): in which the superior transaction manager (TM), after receiving the Commit message from the creator of the transaction, "asks" the enlisted resource managers or the subordinate transaction managers to "prepare" for commit; if all respond with a successful "prepared" answer then the transaction moves to Phase 2, otherwise the transaction is aborted
   - Phase 2 (committing phase) the superior TM writes a durable log entry about the status of the transaction and then starts sending "commit" messages to all the resource managers and subordinate TMs part of the transaction. In the case of any type of error (communication, computer crash etc), the superior TM will continue to send the "commit" messages until a successful "committed" message is received from all the participants. When all the participants responded "committed", the log entry corresponding to the current transaction is removed from the log and the transaction ends.

In addition to the "two-phase commit" technique, MSDTC supports another phase called Phase Zero (Phase0) which occurs after the creator of the transaction calls Commit and before Phase1 starts. To participate in Phase0 you need to enlist as a Phase0 participant: http://msdn.microsoft.com/library/?url=/library/en-us/cossdk/htm/transactionphase0enlistment_6j04.asp?frame=true and http://msdn.microsoft.com/library/?url=/library/en-us/cossdk/htm/pgdtc_dev_8ldf.asp?frame=true. MSDTC will always start with Phase0 and remain there until all the Phase0 participants responded.

The great benefit of Phase0 is that during this phase, any type of enlistment (including Phase0) in the transaction it is still allowed. Once the transaction moves to Phase1, the new enlistments will be denied. Since you can create a new Phase0 enlistment during Phase0, MSDTC executes this phase in waves. After "commit" is issued, the TM will first send "Phase0Request" messages (http://msdn.microsoft.com/library/en-us/cossdk/htm/itransactionphase0notifyasync_8ywk.asp) to all known Phase0 enlistments. If all of them successfully replied Phase0Done (http://msdn.microsoft.com/library/en-us/cossdk/htm/itransactionphase0enlistmentasync_5pt1.asp), the TM will look for new Phase0 enlistments that occurred meanwhile and it will start another Phase0 wave if any is found and so on. Phase0 will end when no other new Phase0 enlistment is found after a wave. After Phase0 ends, the transaction moves to Phase1.

Phase0 allows the following three scenarios: caching resource managers, protection against "early" commits and "safe" propagation of transactions in async programming.

Caching Resource Managers
Using a Phase0 enlistment, a middle-tier component can delay the connection to the database(s) as long as possible, acting as a cache to the requests from the client and thus reducing network traffic and database locks. This works great for those scenarios in which the client does many changes to the same data before it finally decides to end and save the work. When the client "ends" the work, the transaction is committed, and the TM issues a Phase0Request to the caching component. Before replying Phase0Done, the component will open all the necessary connections to the databases that need to be involved and it will persist the final data. These databases will now be "durably" enlisted in the transaction. After Phase0Done is received, the TM will continue with the 2PC and commit the transaction. See also http://msdn.microsoft.com/library/?url=/library/en-us/cossdk/htm/pgdtc_dev_0y2b.asp?frame=true

Protection Against "Early" Commits
In general, 2PC transactions help to ensure integrity of data during different types of system errors. Using Phase0 you can also protect from badly written software.

Let me give an example: let's say a transaction is created on the client side and then propagated to a middle tier component that is asked to do work as part of that transaction. The work that this component needs to do involves two databases, DB1 and DB2, as follows:

int DoTransfer(int amount, transaction tx)
{
DB1.OpenConnection(tx);
DB1.DoDebit(amount);
DB2.OpenConnection(tx);
DB2.DoCredit(amount);
}

The component is using the received transaction to communicate with the two databases to ensure the integrity of its data. Both Debit and Credit operations need to be successful or none should occur. This looks great until now. But what if the client doesn't wait for DoTransfer to finish and calls Commit right after the DB1.DoDebit returned and before DB2.OpenConnection started? A badly written client can do that, maybe the programmer wanted to use multi-threading but didn't quite get it right. What will happen is that the component is left with inconsistent data in the databases, a debit operation that occurred without a credit operation. There is nothing wrong with the transaction itself; from the point of view of the 2PC transaction, only one enlistment occurred and that one responded successfully to both "prepare" and "commit" phases. It is the application logic that is wrong here.

Can you protect against this type of situation? Yes, you can. One way is to write bug-free code, but mistakes happen. If you don't own the client code, the problem is even harder. The best solution is to use a Phase0 enlistment and modify the middle tier code as follows:

int DoTransfer(int amount, transaction tx)
{
EnlistPhase0(tx); //Creates a Phase0 enlistment with the transactions

DB1.OpenConnection(tx);
DB1.DoDebit(amount);
DB2.OpenConnection(tx);
DB2.DoCredit(amount);

SignalWorkCompletedToPhase0Enlistment(tx); // signals the Phase0 enlistment that the work was completed
}

Your Phase0 enlistment should start with a "WorkCompleted" flag set to false. The method SignalWorkCompletedToPhase0Enlistment mentioned above will set this flag to true. If a Phase0Request is received and the flag is still false, it means that the Commit was issued before the DoTransfer finished its work. At this point, you have two options:
- one option (the recommended one when "early commits are not expected) is to abort the transaction and log some error; if you own the client code you might want to catch and fix these "early" commits
- the other option is to hold the Phase0Request, received while DoTransfer is still doing work, until the flag becomes true and only then let the transaction continue by replying with Phase0Done; use this option when you expect to receive "early" commits as part of your system logic and flow.

Asynchronous Programming
This is very similar to the early commits scenarios mentioned above, but this time, the early commits are "by design". One can encounter scenarios where a piece of the application starts a transaction and delegates the work asynchronously to other parts of the application (a different thread of execution, a remote location) and without waiting for a response continues with committing the transaction. In these scenarios, we will choose the second option from above, the one that blocks the commit until work is finished. The code is similar:
Client code:
  Transaction tx = StartTransaction();
  AsyncDoTransfer(tx); // like create a separate thread and let it do the transfer operation etc
  SomeOtherAsyncWork(tx);
  CommitTransaction(tx);

Server code:
  // inside AsyncDoTransfer that receives the transaction from the client
  EnlistPhase0AndBlock(tx); // if we get a Phase0Request we will block and wait until SignalWorkCompletedToPhase0Enlistment is called and only then reply with Phase0Done

DB1.OpenConnection(tx);
DB1.DoDebit(amount);
DB2.OpenConnection(tx);
DB2.DoCredit(amount);

SignalWorkCompletedToPhase0Enlistment(tx); // signals the Phase0 enlistment that the work was completed
return;

Looks nice and safe... Well, there is a problem even with this code. What if, Commit is called even before we are able to enlist in Phase0 in the AsyncDoTransfer method? We can end up again with some inconsistent data. The solution is to create some sort of acknowledgment from the server to the client saying that at least it got to the phase0 enlistment: "hey client, I know I'm slow and I will do your requested work later but here is my ack that you can Commit your transaction safely any time from now on". To accomplish this we will have to use phase0 enlistments on both the client and server side as follows:

Client Code:
  Void MainFunction()
  {
    Transaction tx = StartTransaction();

    EnlistPhase0AndBlock(tx); // if we get a Phase0Request we will block and wait until SignalWorkCompletedToPhase0Enlistment is called and only then reply with Phase0Done
    AsyncDoTransfer(tx, AckFromDoTransfer); // like sending an async message to a server and let it do the transfer operation etc

    CommitTransaction(tx);
}
void AckFromDoTransfer()
{
    SignalWorkCompletedToPhase0Enlistment(tx); // signals the Phase0 enlistment that the work was completed
}

Server Code:
  void AsyncDoTransfer(tx, AckFromDoTransfer)
  {
   EnlistPhase0AndBlock(tx); // if we get a Phase0Request we will block and wait until SignalWorkCompletedToPhase0Enlistment is called and only then reply with Phase0Done

    AckFromDoTransfer(); // the client can Commit safely the transaction from now, since I'm protected by phase 0

    // doing the work that takes a lot of time
    DB1.OpenConnection(tx);
   DB1.DoDebit(amount);
    DB2.OpenConnection(tx);
    DB2.DoCredit(amount);

SignalWorkCompletedToPhase0Enlistment(tx); // signals the Phase0 enlistment that the work was completed
}

The phase0 enlistment on the client side will make sure that we keep the transaction in phase0 until we get all the acks from our servers. Look at this as a method to pass phase0 "ownership" from client to servers.

All these work due to the "magic" of phase0 that allows "infinite" number of enlistments, until no new phase0 enlistments are being created and the existing ones replied with a successful Phase0Done. I compare the Phase0 enlistment to the AddRef method from the good old COM lifetime management. A Phase0 enlistment will call "AddRef" on the "active phase" of the transaction, while a Phase0Done will call "Release" on the counter. While the counter is higher than zero, the transaction will not be allowed to enter Phase1.

Windows Communication Foundation (Indigo) Home Page

florinlazar — Mon, 30 Jan 2006 00:32:00 GMT

Windows Communication Foundation (Indigo) has its own page now at http://windowscommunication.net/