·
·
2 min read

TechEd 2007: transaction features in Windows Server 2008

Hi, Jim Carley here, I work in the directory and service business. My colleague Cuneyt Havlioglu and I presented this morning at TechEd – SVR403 – Building Reliable Solutions Using Transaction Features in Windows Server 2008. Thanks a lot to the folks who were able to make it. If you were not able to be there, here is a very quick summary of what we covered at the session.
 
We talked about the different participants in a transaction (Application, Resource Manager, and Transaction Manager) and how they relate to each other. We then moved into the main topic for this session – configuring MS Distributed Transaction Coordinator in an Active-Active cluster configuration.
 
In Windows Server 2003, you are limited to a single MSDTC cluster resource and in fact, in order to conduct ANY transactions on a Windows Server 2003 cluster, you are required to have an MSDTC cluster resource. This limitation of having only one MSDTC resource introduces the following side effects:
 
1)    Being limited to a single MSDTC resource means that other resources in other groups that need to use transactions experience performance degradation when that application resource runs on a different node in the cluster than the MSDTC resource.
2)    Two transactional application resources that do not have any relationship to each other except for transactions are both affected if the single MSDTC resource fails.
3)    Some products that require transactions to install (such as the action of creating a COM+ package) need to be installed AFTER the MSDTC resource is created, producing install order dependencies.
 
In Windows Server 2008, we solve these issues in the following ways:
 
1)    You can now configure multiple MSDTC resources, one per group (now called “instance” in Windows Server 2008). This allows an application resource to stay co-located with the MSDTC resource it is using, thus avoiding the performance degradation in the event of a failover. In addition, it allows you to make applications with nothing in common except the use of transactions truly separate. Each can have its own MSDTC instance. So the failure of one application group does not affect the others, with respect to transactions.
2)    Now that we allow multiple MSDTC instances, we can also allow the “local” (non-clustered) MSDTC instance to process transactions when there is no MSDTC clustered resource yet configured. This solves the installation ordering problem.
 
There a couple of ways to take advantage of this new feature – programmatically and configuration.
 
Programmatically, a clustered application resource can specify to DtcGetTransactionManagerEx that it is a clustered resource and specify its own cluster resource identifier. Using this information, the MSDTC code finds the “best” MSDTC instance for that application.
 
For applications that haven’t changed to specify this new parameter, the administrator can create a configuration based on executable name, service name, or COM+ application id. The configuration does the same thing – specifies that the application is “clustered” and what its cluster resource name is.
 
There was a wonderful talk about best practices in Windows Server 2008 Clusters (SVR 306) immediately following our talk, but in the completely opposite end of the convention center. There were a lot of folks in that talk that said they used MSDTC in clusters. I guess the timing of the two sessions was not optimal. The Wizard in the Failover Clusters MMC for configuring MSDTC was mentioned, but no mention was made of our Active-Active feature. Hopefully the folks that went to SVR 306 will look through the slides for SVR 403.