What is this LTM thing?

As I mentioned in my previous post on fallback, I've read a number of comments and questions about what the LTM is, and how it works.  Since then I've been caught up in work, in some classes, and I caught the flu.  February was definitely a busy month.

I have continued to think about the promised LTM topic, and try to decide what to say about it.  At one level, I'd prefer to say nothing.  After all, the purpose of the LTM is to act as “go faster“ stripes on the System.Transactions object model.  It isn't supposed to have its own interface, and an LTM transaction isn't supposed to be different than a “normal“ System.Transactions transaction.

So why do we talk about it?  Undoubtedly part of the reason is because we're developers, and it's a cool design.  However, there's also the fact that it is the existence of the LTM that breaks the current notions of basic transaction management overhead found in System.EnterpriseServices and MSDTC.  Since we want to promote transactions as a ubiquitous mechanism, we need to show that very lightweight transactions are possible without leaving the standard classes.  In my mind, that is what is important about the LTM - that it makes very low overhead transactions possible.

Mechanistically, the LTM is a two-phase commit coordinator that operates within an appdomain.  It is co-located with both the application, and any enlistments it is managing.  It restricts itself to coordinating transactions that will not require the TM to log: these are transactions that either are local and have at most one durable enlistment.

Once the LTM faces a transaction topology that exceeds these limitations, it turns itself into a facade layer in front of a “more complete“ transaction manager, such as MSDTC.  All operations continue to pass through the LTM, and it continues to act as a concentrator for any volatile enlistments (thus optimizing the number of notifications that leave the appdomain).

PSPE (Promtable Single Phase Enlistment) is a special case of this.  In PSPE, an enlistment requests to become the “more complete“ TM.  If this request for promotion is allowed, LTM acts as the facade in front of the PSPE-driven TM.  This is like the MSDTC case, except that the PSPE-driven TM can also be asked to provide a fully distributable transaction object, which the LTM uses for propagation and later durable enlistments.  This is also called promotion.

The gist of all of this is that the LTM is the visible transaction manager that the application and the enlistments sees.  It may either be handling the coordination itself, or, if the coordinating TM may need to log in the future, it can be a facade layer in front of a more powerful TM.  You can't “code“ to it -- it is simply always there.  You don't do anything special to get a lightweight transaction, and you will get a non-lightweight transaction as an outgrowth of what you do with the transaction: if you propagate it to another process or appdomain, if you involve multiple durable resources, or if you retrieve the global transaction GUID, you will get a less-than-ligthweight transaction.

Ok, so what is this ILightweightTransaction thing, then?  In .Net 2.0 beta 1, that is the interface for a System.Transactions Transaction that shows that it supports PSPE.  If a transaction has already been promoted to a full distributed transaction, the enlistment can't attempt a PSPE, so it won't necessarily have the ILightweightTransaction interface.

It doesn't have much to do with LTM, except as an outgrowth of the PSPE work.