Jim Johnson and "Adventures in Atomicity"

Please welcome Jim Johnson to the blog world: https://pluralsight.com/blogs/jimjohn/

Jim is the architect of our transactions team and I'm very excited to see him sharing more of his insights in a blog.

Every time I talk with Jim, he opens more and more perspectives on how transactions can change and improve the way we write our software and build our systems. If the first thought about transactions might be that they are for "enterprise applications" only, that need to have fault tolerance, the reality is that "atomicity" can be applied to everything. We just handle the "atomicity" manually today, by using if/then/else or try/catch statements and keeping track of the different states we might be in. Jim made me really dream about the future of transactions and how we can shape them to integrate transparently into our software. If I wasn't enough in love with transactions before, now I really am :)

Comments

• Anonymous
  February 22, 2005
  Welcome Jim :)
  
  Actually, I have a couple of questions concerning System.Transactions.
  
  Do following assertions are rights?
  1) System.Transactions doesn't use COM+ under the hood.
  2) With System.Transactions you won't be able to use another tx manager than MS DTC to deal with your distributed tx.
  3) System.Transactions won't have a compensating mechanism such as the Compensating RM of COM+.
  4) System.Transactions can use some RM through OLE Transactions and WS-AtomicTransaction protocols.In this case it's DTC that deals with these protocols.
  
  Moreover I've noticed that documentations available about System.Transactions don't pinpoint clearly that ADO.NET tx (those with Connection.BeginTransaction()) are not dead. Indeed, in the case of local tx without SQLServer 2005 (with SQLServer 7 or 2000 or other RDBMS) I've noticed that a DTC tx is created which is not the case with ADO.NET tx.
  
  Thanks for your help,
  Patrick
• Anonymous
  February 23, 2005
  Hi Patrick,
  
  1. yes
  2. currently, yes
  3. yes, but it is very easy to write a Compensating RM with the System.Transaction OM
  4. WS-AT support will come with Indigo. And, yes, MSDTC will deal with these protocols
  
  The database internal transactions (offered through ADO.NET) will continue to exist. With most of the databases providing (now or soon) support for promotable single phase enlistments, our recommendation is to use System.Transaction instead of ADO.NET transaction since the performance should be very similar and you also have the advantage that you have built-in support for distributed transactions for free in your product.
• Anonymous
  February 23, 2005
  couldn't be more clear
  thanks Florin
• Anonymous
  February 24, 2005
  Hi Florin
  
  I'm quite in the middle of System.Tx these days :)
  
  Do following assertions are rights:
  1) The LTM deals only with volatile resources.
  2) LTM never crosses appdomain frontiers and thus, deals only with in-memory data.
  3) A single LTM tx is able to enlist several volatile resources.
  4) A difference between volatile and durable resources lies in the fact that if a tx that has enlisted only volatile resources ends up 'in-doubt', no recovery process is needed (since the integrity of corrupted volatile data is not paramount).
  5) Durable resources need the concept of RM (materialized by IResourceManager) only to handle the case of a durable tx that ends up 'in-doubt'. Then the RM plays the role of an identifier (a Guid) toward corrupted data to let a chance to recover them.
  
  Actually I wonder if connections toward SqlSvr2005 are considered as volatile or durable resources. On one hand they don't involve the DTC and thus, can be managed only by the LTM. On the other hand they clearly deal with durable data (that need recovery process in case of a tx that ends-up 'in-doubt').
  
  Finally, from what I understood Longhorn will ship with a third tx engine named KTM, lighter than the DTC but heavier than the LTM. Will the KTM be useful only in the case of tx that enlists some Longhorn resources (file, registry...)?
  
  Thanks for your help,
  Patrick
• Anonymous
  February 24, 2005
  Hi Florin
  
  I'm quite in the middle of System.Tx these days :)
  
  Do following assertions are rights:
  1) The LTM deals only with volatile resources.
  2) LTM never crosses appdomain frontiers and thus, deals only with in-memory data.
  3) A single LTM tx is able to enlist several volatile resources.
  4) A difference between volatile and durable resources lies in the fact that if a tx that has enlisted only volatile resources ends up 'in-doubt', no recovery process is needed (since the integrity of corrupted volatile data is not paramount).
  5) Durable resources need the concept of RM (materialized by IResourceManager) only to handle the case of a durable tx that ends up 'in-doubt'. Then the RM plays the role of an identifier (a Guid) toward corrupted data to let a chance to recover them.
  
  Actually I wonder if connections toward SqlSvr2005 are considered as volatile or durable resources. On one hand they don't involve the DTC and thus, can be managed only by the LTM. On the other hand they clearly deal with durable data (that need recovery process in case of a tx that ends-up 'in-doubt').
  
  Finally, from what I understood Longhorn will ship with a third tx engine named KTM, lighter than the DTC but heavier than the LTM. Will the KTM be useful only in the case of tx that enlists some Longhorn resources (file, registry...)?
  
  Thanks for your help,
  Patrick