| Author |
Message
|
| costasz |
 Posted: Wed Mar 26, 2008 10:05 am Post subject: Failed .Net/MQ/SqlSrvr05 Put in TransactionScope=no rollbck? |
 |
|
Novice
Joined: 26 Mar 2008
Posts: 18
|
code:
protected virtual int GetOutputParams()
{
return MQC.MQOO_FAIL_IF_QUIESCING + MQC.MQOO_OUTPUT;
}
void Put(object objectToPut)
{
using (System.Transactions.TransactionScope scope = new System.Transactions.TransactionScope(System.Transactions.TransactionScopeOption.Required,new TimeSpan (0,10,0)))
{
MQQueueManager mqmgr = new MQQueueManager(managerName, channelName, connectionName);
MQQueue queue = mqmgr.AccessQueue(queueName, GetOutputParams());
MQPutMessageOptions pmo = new MQPutMessageOptions();
MQMessage msg = new MQMessage();
StoreObjectInMsg(objectToPut, msg);
queue.Put(msg, pmo);
DAL.SaveMsg(objectToPut);
scope.Complete();
}
}
This worked ok on a dev box. By "ok" I mean that MQ enrolled in a two phase commit. Today on our prod box, we had a DTC timeout because of too much data in the transaction we were trying to do and this exception was thrown:
Error saving and posting Corp action trades System.Transactions.TransactionException: The operation is not valid for the state of the transaction. ---> System.TimeoutException: Transaction Timeout
--- End of inner exception stack trace ---
at System.Transactions.TransactionState.EnlistPromotableSinglePhase(InternalTransaction tx, IPromotableSinglePhaseNotification promotableSinglePhaseNotification, Transaction atomicTransaction)
at System.Transactions.Transaction.EnlistPromotableSinglePhase(IPromotableSinglePhaseNotification promotableSinglePhaseNotification)
This tells me that a two phase transaction was not in play. Actually our sql inserts were rolled back but the MQ messages were not. What could be going on?
Thanks |
|
| Back to top |
|
 |
| jefflowrey |
| Posted: Wed Mar 26, 2008 10:15 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Even with DTC you can't do two-phase commit with an MQ Client connection.
| WebSphere MQ Programming wrote: |
| Those queue managers can be on different computers if you are using DCOM. Bear in mind that objects that use WebSphere MQ must reside on the same computer as the queue manager that they use. |
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| costasz |
| Posted: Wed Mar 26, 2008 10:43 am Post subject: The MQ Queue Manager and the .Net App were on the same srvr |
|
|
Novice
Joined: 26 Mar 2008
Posts: 18
|
| Anything else that I need to do? The sending app connects to the queuemanager with a a channel and an address but they are on the same physical box. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Wed Mar 26, 2008 10:50 am Post subject: Re: The MQ Queue Manager and the .Net App were on the same s |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
| costasz wrote: |
| Anything else that I need to do? The sending app connects to the queuemanager with a a channel and an address but they are on the same physical box. |
Yes.
You can't use a channel and an address, you have to only use the QMGR name.
I.e. establish a "bindings" connection.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| costasz |
| Posted: Wed Mar 26, 2008 12:13 pm Post subject: Thanks |
|
|
Novice
Joined: 26 Mar 2008
Posts: 18
|
I think my QA DTC testing was done the way you described but in Prod we reverted to using Channel and ConnectionName.
Thanks |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Wed Mar 26, 2008 12:18 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
If you change the configuration in PROD, you've invalidated your QA results...
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| costasz |
| Posted: Tue Apr 01, 2008 12:45 pm Post subject: Re: The MQ Queue Manager and the .Net App were on the same s |
|
|
Novice
Joined: 26 Mar 2008
Posts: 18
|
| jefflowrey wrote: |
| costasz wrote: |
| Anything else that I need to do? The sending app connects to the queuemanager with a a channel and an address but they are on the same physical box. |
Yes.
You can't use a channel and an address, you have to only use the QMGR name.
I.e. establish a "bindings" connection. |
OK, we had to do this because our app runs on a Windows Server 2003 Cluster and for some reason we cannot connect to MQ using just the queue manager name. We even tried putting this app into the same cluster group as MQ and it's still not working. I realize that this has nothing to do with multi-phase commit but since a local queue manager connection is needed to achieve mult-phase commit and a local queue manager cannot be established on a Windows Cluster, we have a problem.
Thanks |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Tue Apr 01, 2008 1:44 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
There shouldn't be any reason that an MSCS configuration would prevent you from establishing a bindings connection - unless you are *NOT* failing over the application with the queue manager, such that the application is always on the *same* machine as the queue manager.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Apr 01, 2008 1:49 pm 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: |
OK, we had to do this because our app runs on a Windows Server 2003 Cluster and for some reason we cannot connect to MQ using just the queue manager name. We even tried putting this app into the same cluster group as MQ and it's still not working. I realize that this has nothing to do with multi-phase commit but since a local queue manager connection is needed to achieve mult-phase commit and a local queue manager cannot be established on a Windows Cluster, we have a problem.
|
Really? I'm typically the 1st person to do Windoze down, but I do wonder what's preventing this. I mean, a queue manager in a WinCluster is just a queue manager, and with a bindings connection you don't even have to worry about TCP/IP. What error code do you get on connect?
In addition to taking out the channel name & address, you did change the transport type, didn't you?
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Tue Apr 01, 2008 5:18 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
oh, and of course recompile linking with the right libraries (server instead of client)... 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| costasz |
| Posted: Wed Apr 02, 2008 5:30 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: |
Really? I'm typically the 1st person to do Windoze down, but I do wonder what's preventing this. I mean, a queue manager in a WinCluster is just a queue manager, and with a bindings connection you don't even have to worry about TCP/IP. What error code do you get on connect?
In addition to taking out the channel name & address, you did change the transport type, didn't you? |
Transport type? I don't know how to do that. We're using the .Net library. I am using this line of c# code to create the queue manager for remote connections
MQQueueManager mqmgr = new MQQueueManager(managerName, channelName, connectionName);
and this for local
MQQueueManager mqmgr = new MQQueueManager(managerName);
Even though I am using the local one I get an error 2277. |
|
| Back to top |
|
|
| costasz |
| Posted: Wed Apr 02, 2008 5:32 am Post subject: Please elaborate. |
|
|
Novice
Joined: 26 Mar 2008
Posts: 18
|
| fjb_saper wrote: |
| oh, and of course recompile linking with the right libraries (server instead of client)... |
Our .Net apps that use MQ have references to only 2 assemblies.
amqmdnet.dll and amqmdxcs.dll |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Wed Apr 02, 2008 5:35 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
I think you need to set NMQ_MQM_LIB or whatever it is.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Apr 02, 2008 5:37 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: |
| Transport type? I don't know how to do that. |
Look it up. The .NET manual describes the 3 kinds of connection supported.
| costasz wrote: |
| Even though I am using the local one I get an error 2277. |
Which (as I'm sure you've discovered from your reading) is a channel definition error. Hence I think it's trying to attach to the queue manager via a client channel. Hence the transport type is client not server (which doesn't use channels).
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| costasz |
| Posted: Wed Apr 02, 2008 6:10 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: |
| Transport type? I don't know how to do that. |
Look it up. The .NET manual describes the 3 kinds of connection supported.
| costasz wrote: |
| Even though I am using the local one I get an error 2277. |
Which (as I'm sure you've discovered from your reading) is a channel definition error. Hence I think it's trying to attach to the queue manager via a client channel. Hence the transport type is client not server (which doesn't use channels). |
I am reading WebSphere "MQ Solutions in a Microsoft .NET Environment". Can u point me to the relevant info in there?
Thanks |
|
| Back to top |
|
|
|
|
