Sign in
 
HomeLibraryLearnSamplesDownloadsSupportCommunityForums
Microsoft Developer Network > Forums Home > Archived Forums Forums > Software Transactional Memory DevLab > What about the TransactionScope class? Will this supercede it?

Locked What about the TransactionScope class? Will this supercede it?

    •  
      Friday, July 31, 2009 4:30 PM
       
       
      Sign In to Vote
      0
      Sign In to Vote

      Two questions:

      1. How does SMN.NET differ from the TransactionScope class? Does it mean that we need to switch from using the TransactionScope class to SMN.NET?

      2. Does SMN.NET also handle database transactions should the code being called in an SMN.NET code block perform a CRUD operation?

      Thanks!

         

      Answers

      • Saturday, August 01, 2009 3:04 AM
         
         Answered
        Sign In to Vote
        1
        Sign In to Vote

        Hi there Natural Remedies,

          

        System.Transactions used syntax “Using (TransactionScoipe scope = new TransactionScope()) { … }” to set the lexical boundaries of the transaction.  STM uses “Atomic.Do” for the same purpose, so your question is very relevant. Let me start from explaining their intended usage:

        a.     If you need only traditional transactions (like SQL or MSMQ),  continue using TransactionScope. These transactions will not serve memory at all – will just work as they were before STM.

        b.     If you need only memory transaction, use Atomic.Do.

        c.     If you need both memory and traditional transactions (e.g. you want ALL-Or-Nothing for variables and MSMQ), also use Atomic.Do.

         

        Pure memory transactions are orders of magnitudes cheaper than those involving persistent resource managers like databases. When you use Atomic.Do, we start cheap, and stay cheap, unless you do some persistent resource manager’s operation, like MSMQ Send or SQL Update. These operations (if instrumented properly) would notice that they are called in a context  of an STM transaction, and upgrade it to a full-blown LTM or DTC transaction. From this point on, it is a LTM or DTC transaction, with STM serving just as another RM.  Note: we did not have time  to instrument SQL resource manager in this release, but did it for MSMQ to prove the concept. It is possible to make wrappers for SQL, but they don’t come out of the box…

         

        Why did we use Atomic.Do with a delegate instead of continuing “Using new TransactionScope” approach?  Because we think it is better, especially now when there are delegates, closures, lambdas... they were not available when System.Transaction  was designed. But they are richer and more robust, and they allow for “pay-for-play” implementation.

         

        Please also see related response http://social.msdn.microsoft.com/Forums/en-US/stmdevlab/thread/d6e9424f-1036-48cb-a2cc-f6e08997841f

         

        Thanks,

        Sasha Dadiomov

        STM team