| Author |
Message
|
| Vitor |
 Posted: Wed Apr 02, 2008 6:16 am Post subject: Re: The MQ Queue Manager and the .Net App were on the same s |
 |
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| costasz wrote: |
I am reading WebSphere "MQ Solutions in a Microsoft .NET Environment". Can u point me to the relevant info in there?
|
No, I'm referring to "Using .NET", the actual manual for the .NET support rather than the redbook.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
 |
| costasz |
| Posted: Wed Apr 02, 2008 8:15 am Post subject: Re: The MQ Queue Manager and the .Net App were on the same s |
|
|
Novice
Joined: 26 Mar 2008
Posts: 18
|
| Vitor wrote: |
| costasz wrote: |
I am reading WebSphere "MQ Solutions in a Microsoft .NET Environment". Can u point me to the relevant info in there?
|
No, I'm referring to "Using .NET", the actual manual for the .NET support rather than the redbook. |
Thanks, I got it. We are about to test it using
NMQ_MQ_LIB value Connection type mqm.dll for Server bindings |
|
| Back to top |
|
|
| costasz |
| Posted: Wed Apr 02, 2008 10:20 am Post subject: Changed our Code to use MQEnvironment and we connected |
|
|
Novice
Joined: 26 Mar 2008
Posts: 18
|
In server binding mode by setting the Hostname and channel to null. Out two-way phase commit transactions still don't work. We checked and the DTC entries are set in the registry.
Thanks |
|
| Back to top |
|
|
| costasz |
| Posted: Thu Apr 03, 2008 10:36 am Post subject: Two phase commit is still a problem |
|
|
Novice
Joined: 26 Mar 2008
Posts: 18
|
MQ is not enlisting in the DTC transaction. This works fine on a standalone server. On this cluster it does not.
Issues addressed:
1) MQ and IIS are now in the same Cluster Group.
2) IIS worker process (thru a web service call) is the process that puts messages on MQ and also writes to SQL Server 2005.
3) The process connects to the queuemanager through local binding (used MQEnvironment to make that work by setting channel name and hostname to null).
4) DTC has these MQ dlls in the registry
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSDTC\XADLL]
"mtxoci.dll"="C:\\WINDOWS\\system32\\mtxoci.dll"
"amqmtsxatm.dll "="C:\\Program Files\\IBM\\WebSphere MQ\\bin\\amqmtsxatm.dll"
"amqmtsxatmc.dll"="C:\\Program Files\\IBM\\WebSphere MQ\\bin\\amqmtsxatmc.dll"
The code is executed inside a .Net 2.0 TransactionScope. When an exception is thrown (intentionally) we can see that only SQL Server 2005 has enlisted. MQ has not.
Any more ideas?
Thanks |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Apr 03, 2008 1:33 pm Post subject: Re: Two phase commit is still a problem |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| costasz wrote: |
3) The process connects to the queuemanager through local binding (used MQEnvironment to make that work by setting channel name and hostname to null).
|
IIRC you still need to change the trasnport type don't you? 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| costasz |
| Posted: Thu Apr 03, 2008 1:41 pm Post subject: Re: Two phase commit is still a problem |
|
|
Novice
Joined: 26 Mar 2008
Posts: 18
|
| Vitor wrote: |
| costasz wrote: |
3) The process connects to the queuemanager through local binding (used MQEnvironment to make that work by setting channel name and hostname to null).
|
IIRC you still need to change the trasnport type don't you? |
I don't know. When I did not set channel name and hostname to null, the MQ Client complained that it could not connect so I assume it was still trying to make a remote connection. Once I nulled those properties out, it connected without having specified a channel or hostname so it had to have used a local binding, don't you think? If not, I'll change the transport type through the registry as well.
Thanks |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Apr 03, 2008 2:03 pm Post subject: Re: Two phase commit is still a problem |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| costasz wrote: |
Once I nulled those properties out, it connected without having specified a channel or hostname so it had to have used a local binding, don't you think? If not, I'll change the transport type through the registry as well.
|
Unless there's a channel table somewhere it's using.
Why the registry? I thought transport was set at environment level through MQEnvironment?
Shows what I know. Maybe you're right, it doesn't work & you need a PMR.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| costasz |
| Posted: Thu Apr 03, 2008 2:08 pm Post subject: Re: Two phase commit is still a problem |
|
|
Novice
Joined: 26 Mar 2008
Posts: 18
|
| Vitor wrote: |
| costasz wrote: |
Once I nulled those properties out, it connected without having specified a channel or hostname so it had to have used a local binding, don't you think? If not, I'll change the transport type through the registry as well.
|
Unless there's a channel table somewhere it's using.
Why the registry? I thought transport was set at environment level through MQEnvironment?
Shows what I know. Maybe you're right, it doesn't work & you need a PMR. |
Yeah, I don't see a direct way to set that thru MQEnvironment. I think it's figured out indirectly by the values in Hostname and Channel. What's a PMR? Program manager? |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Apr 03, 2008 2:20 pm Post subject: Re: Two phase commit is still a problem |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| costasz wrote: |
| What's a PMR? Program manager? |
Program Maintenance Request? Report?  I knew once.
IBM Help Desk ticket to report a fault in the software
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Apr 03, 2008 2:27 pm Post subject: Re: Two phase commit is still a problem |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| costasz wrote: |
| [eah, I don't see a direct way to set that thru MQEnvironment. I think it's figured out indirectly by the values in Hostname and Channel |
I was thinking of MQC.TRANSPORT_PROPERTY in MQEnviroment.properties.
It's inferred from more than that. There's a table in the manual (I just looked it up).
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| costasz |
| Posted: Fri Apr 04, 2008 5:42 am Post subject: Re: Two phase commit is still a problem |
|
|
Novice
Joined: 26 Mar 2008
Posts: 18
|
| Vitor wrote: |
| costasz wrote: |
| [eah, I don't see a direct way to set that thru MQEnvironment. I think it's figured out indirectly by the values in Hostname and Channel |
I was thinking of MQC.TRANSPORT_PROPERTY in MQEnviroment.properties.
It's inferred from more than that. There's a table in the manual (I just looked it up). |
Thanks, I'll look it up |
|
| Back to top |
|
|
| costasz |
| Posted: Fri Apr 04, 2008 6:00 am Post subject: Re: Two phase commit is still a problem |
|
|
Novice
Joined: 26 Mar 2008
Posts: 18
|
| Vitor wrote: |
| costasz wrote: |
| [eah, I don't see a direct way to set that thru MQEnvironment. I think it's figured out indirectly by the values in Hostname and Channel |
I was thinking of MQC.TRANSPORT_PROPERTY in MQEnviroment.properties.
It's inferred from more than that. There's a table in the manual (I just looked it up). |
I added that property to the MQEnvironment.properties. It did not make a difference really as we were already connecting to the local queue manager successfully without specifying a host or channel. Unfortunately, MQ is still not enlisting in the DTC transaction. |
|
| Back to top |
|
|
| JasonE |
| Posted: Fri Apr 04, 2008 2:41 pm Post subject: |
|
|
Grand Master
Joined: 03 Nov 2003
Posts: 1220
Location: Hursley
|
Does the transaction exist when the connection to the queue manager is made? (More precisely, is there a COM context when the connect is made?).
If there is no com context at connect time, then the DTC integration with the transaction wont come into effect even if one appears (as a decision on how to handle the connection needs to be made early) |
|
| Back to top |
|
|
| costasz |
| Posted: Mon Apr 07, 2008 10:44 am Post subject: I was told that the following code would start a COM+ contex |
|
|
Novice
Joined: 26 Mar 2008
Posts: 18
|
using(TransactionScope scope = new TransactionScope(TransactionScopeOption.Required, options, EnterpriseServicesInteropOption.Full) )
{ |
|
| Back to top |
|
|
| liviur |
| Posted: Tue Jul 08, 2008 7:32 am Post subject: PutMessageOptions incomplete |
|
|
Novice
Joined: 15 Nov 2005
Posts: 15
|
| Regardless if you're using a class derived from ServicedComponent or the TransactionScope class, you'll have to "OR" the PutMessageOptions Options property with MQC.MQGMO_SYNCPOINT otherwise MQ will not participate in the transaction. |
|
| Back to top |
|
|
|
|
