Setting up WinXPSP2 or WS2003 for XA transactions with MQ

DotNetInterop — Wed, 06 Jul 2005 21:14:00 GMT

In a previous post, I talked about transactions without components, spanning MQ and SQL Server. The hardest part in doing that was setting up the environment. For posterity, here's what I did:

Steps:

install Windows XPSP2 or WS2003
install the MQ Client or Server software.
install the MQ XA Client (aka "MQ Extended Transactional Client")
install the latest fixpack for WMQ. For Windows v5.3, As of May 2005, this is CSD10.
register the XA DLL in the registry.

for MQ, according to IBM, the DLL is <MQDIR>\bin\amqmtsxatm.dll but on a MQ client-only machine, it may be <MQDIR>\bin\amqmtsxatmc.dll

For MQ then, it is:
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSDTC\XADLL]
Key name: amqmtsxatm.dll
Data: C:\progra~1\ibm\MQ\bin\amqmtsxatm.dll

If you are running the app from an MQ client node, get the interim fix from IBM; I don't know which fix this is. you have to request it. It is not included in CSD10. It may be included in CSD11. If you are running the app on a MQ server node, then you do not need the interim fix.
Turn on DTC in Windows. This is slightly different on XPSP2 and WS2003. On XPSP2, it is like this:
Control Panel--> Admin Tools --> Component Services --> My Computer --> Properties

select the MS DTC tab, click the "Security Configuration..." button.
Check the "Network DTC Access..." box.
Check the XA box.

allow the "network service" user to read the directory in which the XA DLL resides.

Use Explorer for this. For my install of MQ, this directory is
c:\progra~1\ibm\mq\bin\
add "network service" user to the MQM group (or other group authorized to "perform XA recovery" on MQ).
set the NMQ_MQ_LIB variable to c:\progra~1\ibm\mq\bin\mqic32xa.dll. This is from the "Using .NET" doc.)
Run the app

That's it.

[addendum, 13 October 2008: An attentive reader has pointed out that

the WebSphere MQ Solutions in a Microsoft .Net Environment (SG24-7012-00) states:

“WebSphere MQ applications can participate in transactions managed by Microsoft transaction managers. The application either has to be directly connected to a queue manager, or it has to use the extended transactional client function when running on a remote machine.”

So my assertion above, that you need the Extended Transactional Client, may not be appropriate in all cases. When in doubt, prefer the IBM documentation. Better yet, contact IBM for full details. I'm not even sure the Extended client still exists for MQ V6.0 and beyond.

Transactions, SwC, and IBM MQSeries

DotNetInterop — Wed, 06 Jul 2005 18:28:00 GMT

In .NET 2.0 (code-named "Whidbey"), Microsoft is introducing a bunch of slick enhancements and extensions to the programming model for transactions. Much of this is available through the new System.Transactions namespace. There's a whitepaper, Introduction to System.Transactions, available since April.

One of the nice things about Whidbey is the introduction of the TransactionScope class into the .NET Framework. This gives developers another option in programming their transactional work. A code snippet from that whitepaper shows the model I am talking about:

using(TransactionScope scope = new TransactionScope()) {

/* Perform transactional work here */

//No errors - commit transaction

scope.Complete();

}

For those of you who have been around for 10+ years, it looks very much like Tran-C or Tran-C++, from Transarc's Encina (Graeme Dixon, the father of Tran-C, is now a distinguished engineer at IBM. Transarc was acquired by IBM in 1994).

It's a nice advance for .NET developers, and System.Transactions will bring other benefits, too. Some nice optimizations for one-phase commits, for example. But actually, you can get a similar the using(ts= new TransactionScope()){ } programming model with .NET v1.1. The code looks essentially the same :

using( TxUtil.ESTransactionScope ts = new TxUtil.ESTransactionScope()) {

// do transactional work...

ts.VoteToCommit = true;

}

Now, some disclaimers: for .NET v1.1, this is not "built-in" to the framework, which means you, the apps programmer, have to provide and maintain the code for the TransactionScope class. Also, it depends on COM+ stuff that is available only in Windows Server 2003, and Windows XP SP2, so if you use Windows 2000, you can't get this.

But on the supported platforms, the code required to implement it yourself is pretty trivial, and examples abound. It has been called "Services without components", and the doc on MSDN mostly focuses on C/C++ developers, but it is also easily employed by .NET v1.1 devs using VB or C#.

A while back, Microsoft used this sort of programming model in a benchmark, and IBM had claimed that this was a really advanced technique: "To decide to code the distributed transactions with ServiceDomain classes ... shows a deep amount of technical skill." But it's not true. It's actually simpler than using ServicedComponents, in my book. Using the ServiceDomain class in .NET V1.1 is pretty straightforward. You can use transactions without deriving from the ServicedComponent class, and without configuring that component in the COM+ catalog. In short, it makes the high-performance Windows transaction engine more easily accessible to more programmers, and that's good.

Umm, Interop?

Yes, so the SwC programming model is nice, and it gets nicer in .NET 2.0 (aka "Whidbey"). The obvious next question here is, what about interop with non-Microsoft transactional resources? If you've been reading other entries on this blog you won't be surprised to learn that it just works. The SwC programming model does not introduce a new transaction engine. It is merely a new programming interface on the built-in platform transaction engine, formerly known as COM+. So, what works with the "traditional" COM+ programming model also works with SwC.

A great example is IBM MQSeries. In financial services enterprises, MQ is near-ubiquitous. It seems to be the preferred mechanism for linking anything to mainframe systems. And there are numerous programming interfaces for MQ - including C/C++, COBOL, RPG, Java, and, since September 2003, a .NET assembly. IBM introduced "the MQ Classes for .NET" as a new feature in MQ v5.3 CSD05, at that time. That allowed any .NET app to connect to MQ in a pretty simple manner. IBM did the integration with COM+, so an app that connects to MQ and another transactional resource manager, for example, MS SQL Server, can perform updates across both of them as a single logical unit of work, with ACID guarantees. The canonical example is, dequeue a message, then update a database based on the content of that message.

For an MQ app using the .NET classes from IBM, the MQ client library will automatically enlist in a transaction created programmatically via System.EnterpriseServices.ServiceDomain.Enter(). The doc in the IBM Redbook, WebSphere MQ Solutions in a Microsoft .Net Environment (SG24-7012-00) discusses transactions via COM+ configured components, but does not mention SwC. I am here to tell ya, when you access MQ, the same transactional guarantees are available whether you use traditional COM+ interfaces or SwC.

It's really pretty simple. Within the transactional work, you need to ask for syncpoints on the Get() or Put(), eg gmo.Options|= MQC.MQGMO_SYNCPOINT, or pmo.Options|= MQC.MQPMO_SYNCPOINT. The hardest part for me was installing and configuring Windows XP SP2 and MQ to allow XA transactions. I have a separate post for that.

I packaged up a sample, including source code, for you to try. For comparison purposes, I also included a sample that shows transactions spanning MSMQ and SQL Server, using the same programming model. (Like MQ, MSMQ also automatically enlists in ambient transactions.) Enjoy, and let me know what you think!

download the sample code

-Dino

All About Interop : Transactions

Setting up WinXPSP2 or WS2003 for XA transactions with MQ

Transactions, SwC, and IBM MQSeries

Umm, Interop?