Vista: An MSDTC proxy enhancement (MLTM)

MSDTC has had a structure where there is a proxy (msdtcprx.dll) located in the user's process.  This implemented the Oletx API, managed some local state, and a set of communication channels back to the MSDTC service (msdtc.exe).  Much of the processing went on in the MSDTC service -- almost all of it, in fact.

Given the transaction topologies that MSDTC would be involved in, this had been a reasonable design choice.  Transactional resources were located in server processes, so multiple processes, and quite often multiple systems, were involved.  That meant that these transactions were going to migrate to the MSDTC service process anyway.  The only thing that could be up for debate was whether or not the transaction went to the MSDTC service when it was created, or a millisecond or so later.

That began to change with System.Transactions.  The amount of logic in the user process went up, the capability went up, and new mechanisms (such as the promotable single phase enlistment) were introduced that kept the transaction local to the process, even if it involved a database.  Even if the transaction should promote to Oletx, System.Transactions would continue to do what it could to limit the amount of information that would flow back to the MSDTC service.  For instance, volatile enlistments and transaction outcome notifications are multiplexed in the user process, and may not be represented back at the MSDTC service at all.

With Vista, we also had some new topologies to consider, most especially ones that involved the transactional file system (TxF) or registry (TxR).  In those cases the transacted resource is not in another process.  More importantly, there is no failure mode where TxF or TxR can fail catastrophically and the user process not be impacted.

Consequently, we've added logic in the MSDTC proxy to be able to create transactions, multiplex voters and outcomes, and manage TxF or TxR resources without going to the MSDTC service.  Much like System.Transactions, the proxy will automatically promote to the MSDTC service if the topology requires it.  This feature is internally called "MLTM".

Consider the implications of this.  If you look at the example code shown here, you'll note that System.Transactions acquires the DTC ITransaction interface in order to pick up the kernel transaction handle.  Prior to Vista, this would have promoted the transaction to the MSDTC service, but no longer.  That example should never leave the user process, never add any additional log writes, and only involve the minimal transaction mechanisms in order to execute.