Using distributed transactions in .Net 1.x without deriving from ServicedComponent


The most used feature of System.EnterpriseServices or COM+ is the distributed transaction support. And the automatic transaction programming model in ES using attributes ([Transaction] and [AutoComplete]) is great and nice but (it is always a but!)… you need to inherit from ServicedComponent and the Transaction attribute is only available at class level, and you need to register your component in the COM+ repository and the list can continue.


If doing this seems overkill to you, because all you need is a distributed transaction to protect your code/actions and you don’t care of any of the others ES features (which are great ones nevertheless) then there is a solution for you: System.EnterpriseServices.ServiceDomain. Here is some sample code:


using System;
using System.EnterpriseServices;


namespace SDSample
{
   class Class1
   {
      [MTAThread]      
      static void Main(string[] args)
      {
         ServiceConfig config = new ServiceConfig();
         config.Transaction = TransactionOption.Required;
         ServiceDomain.Enter(config);
         try
         {
            MyTxCode();
         }
         catch(Exception e)
         {
            // we got an exception
            Console.WriteLine(e.Message);
            // so, we should abort the transaction
            ContextUtil.SetAbort();
         }
         finally
         {
            ServiceDomain.Leave();
         }
      }


      // The code that I want to be transactional
      static void MyTxCode()
      {
         Console.WriteLine(ContextUtil.TransactionId);
                 
         // Open connection to database 1
         // Execute update in database 1
 
         // Open connection to database 2
         // Execute update in database 2
      }
   }
}


Of course, you can go further and create a helper class, let’s call it ESTransactionScope (similar to System.Transactions.TransactionScope that will arrive in Whidbey) that will be very easy to use:


using System;
using System.EnterpriseServices;


namespace SDSample2
{
   class Class1
   {
      [MTAThread]      
      static void Main(string[] args)
      {
         using( ESTransactionScope ts = new ESTransactionScope())
         {
           MyTxCode();


           // Everything went well, no exception thrown
           // so let’s vote for Commit
           ts.Complete();
         }
      }
 
      static void MyTxCode()
      {
         Console.WriteLine(ContextUtil.TransactionId);
             
         // Open connection to database 1
         // Execute update in database 1
 
         // Open connection to database 2
         // Execute update in database 2             
      }
   }
 
   // Used to create transactional code blocks
   class ESTransactionScope : IDisposable
   {
      // Dispose must be called to exit the transactional block
      public void Dispose()
      { 
         if(this.EnterSucceeded)
         {              
            if(!this.Consistent)
            {
               ContextUtil.SetAbort();
            }
            ServiceDomain.Leave();
         }
      }


      // by calling this method, you mark the scope as being consistent
      // and ready to for commit
      // if the method is never called, upon dispose, the scope will abort the transaction
      public void Complete()
      {
         this.Consistent = true;
      }  
 
      public ESTransactionScope()
      {                
         EnterTxContext(TransactionOption.Required);
      }
 
      public ESTransactionScope(TransactionOption txOption)
      {
         EnterTxContext(txOption);
      }
 
      private void EnterTxContext(TransactionOption txOption)
      {
         ServiceConfig config = new ServiceConfig();
         config.Transaction = txOption;
         ServiceDomain.Enter(config);
         // Since Enter can throw, the next statement will track the success
         // In the case of success will we need to call Leave in Dispose
         this.EnterSucceeded = true;          
      }
 
      // By default, the scope is inconsistent;
      // To Commit the transaction on exit, the Consistent flag
      // must be set to true before Dispose is called
      private bool Consistent = false;


      // Enter can throw, so we need to know if we need to call Leave in Dispose
      private bool EnterSucceeded = false;
   }
}


System.EnterpriseServices.ServiceDomain is available only on XP SP2 (or higher) and Windows Server 2003 and only in .Net 1.1.


If you need your app to work with .Net 1.0 or on Windows 2000 or XP pre-SP2, you can use the trick that Don Box posted at http://www.gotdotnet.com/team/dbox/default.aspx?key=2004-07-12T08:40:44Z  It uses exactly one transactional ServicedComponent based class and a DoCallback method to which you pass the delegate to your MyTxCode function that needs to execute in a transaction.

Comments (19)

  1. Milo says:

    Hi

    Has anyone managed to try this code successfully and change the isolation level? ie. Something like:

    objServiceConfig.IsolationLevel=EnterpriseServices.TransactionIsolationLevel.ReadUncommitted

    It seems to work nicely untill you try to change the isolationlevel (the stting is ignored).

    Regards

    Milo

  2. Alex Thissen says:

    Nice entry.

    This also works with XP SP1 if you have the appropriate Windows Update provided fixes installed. See also my blog-entry: http://www.alexthissen.nl/Weblog/PermaLink.aspx?guid=f6d61461-d336-40b0-9f4d-51eab6650f27. FWIW, there is also an entry on TIP transactions using ServiceConfig and ServiceDomain.

  3. Hi,

    personally I think that what’s great about MTS-style transactions is that they are declarative, not that they are distributed.

    Not quite often you need to target different stores. On the other hand, declarative transaction keep you domain/model – business/layer far from database transactions details. I think one typically thinks about transactions in term of business-application level transactions, not database transactions; that’s why declarative transactions are so great…

    I’ve used mts style transaction a logt in COM despite their impact on perfomances, however in my opinion using servicedcomponents in net 1.1 has so many twists and turns , and deploymenent requirements and bugs and .. that I had to drop it.

    The solution proposed here is very interesting and drops all these twist and turns. Unfortunately the problem is that it isn’t declarative stuff any more.. so it’s ok for distributed transactional needs "only".

    I developed a custom .NET data provider on my own to make transaction flow transparent to business-layer code .. you can find more info in my blog.

    my 2 cents

    enrico

  4. I forgot to say that obviously I’d like a [Transaction.Required] attribute that spins up a local transaction and promote to distributed only when needed.

    Is this supposed to be supported on .net 2.0 ?

  5. Marcelo Lavio says:

    Hi,

    To Milo: Yes, I’ve changed successfully the TxIsolationLevel but to ReadCommitted (I never tried to change it to ReadUncommitted). So, i can say that, in general, changind the TxIsolationLevel works. But, if ReadUncommitted setting got ignored, it may be due to a bug on COM+ transactional services handling this kind of setting.

    To Florin: I’m trying the approach suggested here (using the ESTransactionScope class) on a project I’m working on. The code is nice, but I think a little change to the ESTransactionScope class is in order:

    If, for some reason, ServiceDomain.Enter() call on the EnterTxContext() method throws an exception, there will be no way to match the ServiceDomain.Enter() with a corresponding ServiceDomain.Leave() as required on the remarks of the ServiceDomain class overview (http://msdn.microsoft.com/library/en-us/cpref/html/frlrfSystemEnterpriseServicesServiceDomainClassTopic.asp).

    My suggestion is that the ESTransactionScope constructor shall only set the ServiceConfig object (like, for instance, the constructor of SqlConnection, which can be used to set up the connection string). Then the class should have Open() method (to set an IsOpen boolean private flag and call ServiceDomain.Enter()) and Close() method (to, if the IsOpen flag is true, set the IsOpen flag to false and call ServiceDomain.Leave()). The Dispose() method can then be changed to just call Close().

    That’s my 2 cents.

    Marcelo

  6. Marcelo Lavio says:

    Hi Florin,

    I’ve done a deeper testing on COM+ Services Without Components and this ESTransactionScope class, and I found what I think is an important flaw on COM+ 1.5 SwC implementation.

    This is the situation: supose three "components", all of them are transactional (transaction required). Let’s say that one component has a method that is the transaction root (let’s call it Component1.MethodTransactionRoot) and this method calls one method on the second component (Component2.MethodNestedCall1), and then a method on the third component (Component3.MethodNestedCall3) as per the following pseudo code:

    // on client

    static void Main(string[] args) {

    for (int i = 0; i < 3; i++) {

    try {

    Component1 component1 = new Component1();

    component1.MethodTransactionRoot();

    catch (Exception e) {

    Console.WriteLn(e.ToString());

    }

    }

    }

    // on Component1

    public void MethodTransactionRoot() {

    Component2 component2 = new Component2();

    component2.MethodNestedCall1();

    Component3 component3 = new Component2();

    component3.MethodNestedCall2();

    }

    // on Component2

    public void MethodNestedCall1() {

    // do some transaction, vote for abort but do not throw an exception

    // if this is a serviced component deactivate it on return

    }

    // on Component3

    public void MethodNestedCall2() {

    // do some transaction and vote for commit

    // if this is a serviced component, deactivate it on return

    }

    If all this three components are traditional ServicedComponents (extending System.EnterpriseServices.ServicedComponent), at the time Component1.MethodTransactionRoot() calls Component3.MethodNestedCall2() you got an System.Runtime.InteropServices.COMException ((0x8004E003): You made a method call on a COM+ component that has a transaction that has already aborted or in the process of aborting.) as expected as the code in Component2.MethodNestedCall2 is bad code, because it didn’t throw an exception, so the calling code tried to continue using a doomed transaction.

    But, besides that, as the Main() method continues to call Component1.MethodTransactionRoot(), every thing is the same, over and over again, as it should.

    The behaviour is completelly different if the code, instead of ServicedComponent, uses COM+ 1.5 SwC on each of the three components (where each "transactional" method calling ServiceDomain.Enter() and ServiceDomain.Leave()). As expected the same COMException will be thrown, at the same point in code, on the first call of the Main() method to the Component1.MethodTransactionRoot(). But all the other calls will fail when Component1.MethodTransactionRoot() calls ServiceDomain.Enter() again, when executing the other calls made from Main() method.

    The point is that if you call ServiceDomain.Enter() on a doomed transaction (a transaction that is aborting), you enter a non recoverable state that will prevent any furter success call to ServiceDomain.Enter() until you shutdown your application and then restart. This is much different than the behaviour of traditional ServicedComponents, and I consider it a flaw.

    As there is no fail safe way to detect if you are running a doomed transaction before make a call to ServiceDomain.Enter(), if any point of application code is sloppy (does not throw an exception when it votes for transaction abort), you risk to put the whole application down until next application restart.

    As per my tests, every call to ServiceDomain.Enter() creates a new COM+ Context (verified by calls to ContextUtil.ContextId), and every call to ServiceDomain.Leave() terminates that context.

    The problem happens when ServiceDomain.Enter() is called in a context which has a doomed transaction. The implementation of ServiceDomain.Enter() does some wrong thing in context management, and no call to ServiceDomain.Leave will be able to terminate the contexts that were created by the previous calls to ServiceDomain.Enter(). You can verify that using sucessive calls to ServiceDomain.Leave(); ContextUtil.ContextId; which returns the same ContextId over and over again (with transactional status ‘Committed’).

    Hope you can tell if this behaviour is "by design" or that you can carry this info to someone at Microsoft for further investigation.

    Thanks,

    Marcelo Lavio

    PS.: Platform of tests is Windows 2003 Server, COM+ 1.5, .NET 1.1. I can send test code which demonstrates the problem. If interested, plese write to mlavio (at) hotmail dot com.

  7. gxh973121 says:

    Ping Back来自:blog.csdn.net

  8. xdev says:

    Ping Back来自:blog.csdn.net

  9. Ambient transactions are defined as transactions that live in current thread or object context that anybody…

  10. florinlazar says:

    To: M. Lavio

    The bug that you are mentioning about calling Enter on an aborted transaction it is now fixed in Windows Server 2003 SP1. It will be also fixed in XP SP3. If you need the fix sooner, you can call Microsoft Support and ask for COM+ Rollup 9 for Windows XP.

  11. rjn says:

    Florin,

    My application is running on windows2000,so serviceconfig won’t work. You suggested using DonBox’s approach at this url. http://www.gotdotnet.com/team/dbox/default.aspx?key=2004-07-12T08:40:44Z

    I’m unable to find this url. Can you post the correct url please.

    Thanks

  12. Yeah, I am back on the ES kick again.&amp;nbsp; Some EnterpriseServices links to ponder.

    Using Distributed…

  13. A naive question: If instead of using a console app for this demo, can I use/call ESTransactionScope() inside a .NET 1.1 ASMX Web service [WebMethod]?

    Anything special I have to do?

    Part of my question is: do I have declare any special threading attributes (e.g. [MTAThread]) anywhere in my ASMX Web service class?

  14. florinlazar says:

    To: Michael

    No, nothing special as far as I’m aware of.