MSDTC changes in WS2008, Part 4: Miscellaneous features

Parts 1, 2, and 3 covered most of the mainline MSDTC features that show up in WS2008.  And now we come to the end with three more, relatively minor, topics: VSS integration, changes in XA support, and some changes in MSDTC tracing.

VSS Integration

This isn't strictly speaking a WS2008 feature, as it was mostly present in Vista.  However, it is a good example of a 'good Windows citizen' change.

Traditionally, transaction managers have had little to do with backup.  They manage a log that is assumed to hold very short lived data.  In turn, that data only makes sense in conjunction with other data stores (i.e. either other transaction manager or resource manager logs).  And, there is normally no automated way to handle the multiple data stores being out of sync.  MSDTC is no different in any of these regards, and all of these reasons are still valid with Vista.

However, there is a role that a transaction manager can play.  Consider taking a live backup of a volume where you have a number of transaction aware resources.  The ideal backup is no longer a crash consistent point in time view of the data.  It is a crash consistent point in time where all the active resource managers will recover their transactions in the same way on restore -- in other words, a transaction consistent point in time.

VSS, the Kernel Transaction Manager, and MSDTC were changed during Vista to support this mode.  VSS now asks the transaction managers at the appropriate times to establish a transaction consistent point.  This is one where all impacted resources that have received a phase 2 (commit) notification have acknowledged processing it.  Once that has been reached, all the resources are directed to take their snapshots, and then the transaction manager is released to continue processing.

Each resource manager, when recovering from a VSS restore, will automatically abort all transactions that were in flight or in doubt.  This means that they will all restore to the same logical point in time, given the volume a transaction consistent restore.

XA Support

In part 3, I described how MSDTC now automatically reconnects to the correct MSDTC instance during recovery for any given transaction.  By default, that feature also works for XA-based resource managers.

In order for MSDTC to do this, it had to add some data to both the PrepareInfo structure and to the XA XID.  The PrepareInfo structure was already variable length, but the XA XID was packed into a format that had typically been more static in its size.  Normally, there is no problem with the new fields.  However, the format and size of these structures did change, and that could cause some resource managers difficulty.

Because of this, as of Vista SP1 and Windows Server 2008, MSDTC supports a degraded mode of operation which restricts a resource manager to both the pre-Vista recovery data formats and to working with, and only with, the default cluster resource MSDTC instance.

In order to select this mode, the resource manager needs to call DtcGetTransactionManagerEx as follows:

hr = DtcGetTransactionManagerEx (

            NULL, NULL, riid,

            OLE_TM_FLAG_NOAGILERECOVERY, // 0x00000002

            NULL, &pvRiidObject);

As you can see, this requires that the default be selected, and the flag will force this to use the default cluster resource instance.

Changes in tracing

MSDTC has long had both the administrative transaction tracing and a growing set of fault analysis trace features.  The latter are increasingly useful in tracking down issues quickly and resolving them.  During Vista and Windows Server 2008, the transactions team worked on rationalizing the tracing, extending it to cover more of our own problem resolution scenarios, and incorporating suggestions and feedback from PSS.  From what I saw, we ended up with much more extensive tracing than we'd previously had, with a result that we were able to debug problems during development much more quickly than in the past.

While they are mostly meant for internal consumption, they might be interesting for some intrepid spelunker.  I was going to provide a rundown of the traces, but I ran across http://support.microsoft.com/default.aspx/kb/926099, which already does that, and better.

And that brings my lap around the changes in MSDTC to a close.  It has some very significant new features, ones that I believe and hope will prove useful to many customers.

Jim.