How transaction fallback works.

A recent comment asked for a longer explanation about how transaction fallback works.  In general, I've seen a lot of interest and questions about this, and about the LTM in general.  Although strongly related to fallback, I'm going to address some thoughts about the LTM in my next post.

The idea behind transaction manager fallback, aka “pay for play”, is to use a sequence of transaction management engines.  These engines begin with one that is strongly limited in scope, and heavily optimized within that scope.   The sequence continues one using ever more general purpose engines, culminating in the use of a fully general, distributed transaction management engine (MSDTC, in our case).  The process of moving from a more constrained engine to a less constrained one is called fallback.

In .Net 2.0, there are three possible stages that a transaction can go through: it begins under the control of the LTM, it may then be promoted to a database transaction through promotable single phase enlistment (PSPE), and finally, it may be promoted to MSDTC.

All transactions begin under the LTM.  The LTM relenquishes control of a transaction either when a resource manager requests it through PSPE or when the transaction topology may require logging in the future.  The first case is pretty clear, so let's consider the second.

The LTM assumes that all volatile resources share the same failure behavior as itself -- that is to say that if the LTM fails, so do the volatile resources.  It furthermore assumes that other app domains and processes may not share the same failure behavior (i.e. it may fail, but the other app domain may still be up).  It also makes this same assumption about durable resources.  Given this, the LTM will promote to MSDTC if it a) is requested to marshall a transaction for another app domain or process, or b) if more than 1 durable resource is enlisted.  Note that even if it does promote to MSDTC, the LTM will continue to act as a facade layer, and will also be a concentrator for all local volatile resources (this last point reduces traffic and performance cost when the promotion does happen).

Note that these same points will also result in the LTM revoking the transaction control from a PSPE-enabled resource, for many of the same reasons.