| Author |
Message
|
| drenshaw |
 Posted: Wed Sep 22, 2004 3:19 am Post subject: MQ5.3 CSD7, .NET API, COM+ distributed transaction enlisting |
 |
|
Newbie
Joined: 22 Sep 2004
Posts: 6
|
Hi,
I am writing a transactional .NET application using Windows 2000 COM+ DTC for transaction coordination.
I have been following the guidance in the "WebSphere MQ Solutions in a Microsoft .NET Environment" red book. In particular the "Automatic transactions using .NET declarative transaction management" on page 297.
However, the WMQ does not appear to be being enlisted in the COM+ transactions automatically and rollbacks are not occuring as they should when an exception is thrown.
I have confirmed that a COM+ transactional context exists when all of the MQ work is done.
Now, I have looked all of the net and through these forums for people having similar problems in the past. I have not found any conclusive answer but there were suggestions that there was a difference between "client" connections and "server" connections when it came to transaction enlistment.
I am connecting to a local queue and I believe I have the WMQ client software installed so does this mean that I cannot test transaction enlistment at present?
The final production environment will be using an WMQ server hub so maybe transaction enlistment will work then. If so, how should I test it prior to deployment?
I can provide a simple example .NET application that demonstrates this problem if it might help anyone.
Thanks,
Daniel Renshaw |
|
| Back to top |
|
 |
| jefflowrey |
| Posted: Wed Sep 22, 2004 4:21 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
If you are not running your program on the same machine as the queue manager itself, or if your program has set NMQ_MQ_LIB to mqic32.dll, then you are running as a client.
If you are running as a client, you can not participate in two-phase commits.
Unless you are running the Extended Transaction Client - in which case you would have to set NMQ_MQ_LIB to mqic32XA.dll.
But I believe that the ETC doesn't support MTS transactions - so you probably can't use it for your app anyway.
So, yeah, run on the same machine as a queue manager, and link against mqm.dll, and see if you have the same problems.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| drenshaw |
| Posted: Wed Sep 22, 2004 4:31 am Post subject: |
|
|
Newbie
Joined: 22 Sep 2004
Posts: 6
|
Thanks for the response.
The queue manager is running on the same machine as the application but I'm pretty certain that I don't have the server software installed, nor do I have the extended transactional client installed.
Daniel |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Wed Sep 22, 2004 4:40 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
If the queue manager is on the same machine as your application, then that machine has the server software installed. You don't get queue managers otherwise.
So what library are you linking against?
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| drenshaw |
| Posted: Wed Sep 22, 2004 7:01 am Post subject: |
|
|
Newbie
Joined: 22 Sep 2004
Posts: 6
|
Yep, you're right I do seem to have the server software installed after all. Unfortunately, this concerns me as I no longer have a possible explanation for the transaction enlistment to not work!
As I am programming with .NET I am not linking to any library as such. Instead I have a reference to the .NET API library amqmdnet.dll.
Daniel |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Wed Sep 22, 2004 7:33 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Yes yes. .NET = dynamic binding. I know that.
What is the value of NMQ_MQ_LIB?
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| drenshaw |
| Posted: Thu Sep 23, 2004 8:10 am Post subject: |
|
|
Newbie
Joined: 22 Sep 2004
Posts: 6
|
I've set the NMQ_MQ_LIB environment variable to "mqm.dll" to enable server binding but I'm still not seeing enlistment in the transactions.
Daniel |
|
| Back to top |
|
|
| JasonE |
| Posted: Fri Sep 24, 2004 12:08 am Post subject: |
|
|
Grand Master
Joined: 03 Nov 2003
Posts: 1220
Location: Hursley
|
| Asking the obvious, but are you using syncpoiint on your MQ operations? |
|
| Back to top |
|
|
| drenshaw |
| Posted: Fri Sep 24, 2004 1:11 am Post subject: |
|
|
Newbie
Joined: 22 Sep 2004
Posts: 6
|
| I'm glad you're asking the obvious - I'm sure I'm doing something silly. However in this case I can confirm that I am using a sync point. The Put Message Options, Options property is set to 2, i.e. MQPMO_SYNCPOINT is the only option set. |
|
| Back to top |
|
|
| drenshaw |
| Posted: Fri Sep 24, 2004 1:17 am Post subject: |
|
|
Newbie
Joined: 22 Sep 2004
Posts: 6
|
EEP!!! Although I was creating a MQPutMessageOptions object and setting the options property with MQPMO_SYNCPOINT I had forgot to use the options when actually calling Put!
The operations are now being enlisted in the distributed transaction. Thanks for your help.
Daniel |
|
| Back to top |
|
|
|
|
