| Author |
Message
|
| rajeessh |
 Posted: Tue Apr 11, 2006 4:47 am Post subject: Problem with call to Begin for starting Transaction - DotNet |
 |
|
Newbie
Joined: 03 May 2004
Posts: 8
|
I am writing a class to support read and write operations into MQ.
My machine is Win2K with IBM WebSphere MQSeries 5.3 with CSD12 installed.
I am able to read or write messages.
When I call backout/commit the message also rolls back/commits
I have used SYNCPOINT options in the PutOptions.
But as I require a two phase commit I am trying to use the Begin statement to ensure that my transacton is started.
But in the call to Begin I am getting a MQError as MQRC_HCONN_ERROR AND Reason as 2018.
The code to start a transaction is as follows.
public bool StartUnitOfWork(CMQRESULT mqResult)
{
m_qMgr.Begin();
mqResult.CompletionCode = m_qMgr.CompletionCode;
mqResult.ReasonCode = m_qMgr.ReasonCode;
mqResult.Result = (mqResult.CompletionCode != MQC.MQCC_FAILED);
return mqResult.Result;
}
If any experts could help it will be great.
_________________
Srinivasan Rajesh
IT Consultant |
|
| Back to top |
|
 |
| fschofer |
| Posted: Tue Apr 11, 2006 5:01 am Post subject: |
|
|
Knight
Joined: 02 Jul 2001
Posts: 524
Location: Mainz, Germany
|
Hi,
i would start to lookup in the documentation
for the description of 2018 / MQRC_HCONN_ERROR.
Greetings
Frank |
|
| Back to top |
|
|
| rajeessh |
| Posted: Tue Apr 11, 2006 5:04 am Post subject: |
|
|
Newbie
Joined: 03 May 2004
Posts: 8
|
The list was as below and as I am not able to figure out the issue
No xmitq name specified in the qremote definition
Max conn limit exceeded
Compile error
Hconn variable error in application
Language environment setting (affected variable initialization)
Use of nested MQCONNs (this is not supported)
Unsupported version of COBOL.
Application compiled with threaded lib instead of non-threaded lib
Use of MQ header file from a different MQ platform than application was run
Problems with dynamic calls in application
2018 when using Micro Focus Animator
Application passed incorrect value for hobj on MQCLOSE. Returned 2018 on MQPUT
Program link error
2018 for an application after upgrading z/OS® to the 1.5 level, and WebSphere® MQ from V5.3. to V5.3.1. The 2018 was related to not specifying LE reporting options (using the CEEROPT setting).,Once this was set the MQRC_HCONN_ERROR cleared, and the application was fine. You found the error was not caused by MQ at all. It turns out the programmer had to enlarge a buffer in his code to fix the error. The error was not caused by MQ and the buffer change fixed the error.
_________________
Srinivasan Rajesh
IT Consultant |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Apr 11, 2006 5:10 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
Try searching for 2018 & .NET in this forum using the search tool above. It seems to be a common error, or at least there's been a lot of discussion on it. With luck some of it will point you in the right direction.
(I am not now nor have I ever been a .NET programmer!) 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| mvic |
| Posted: Tue Apr 11, 2006 5:14 am Post subject: Re: Problem with call to Begin for starting Transaction - Do |
|
|
Jedi
Joined: 09 Mar 2004
Posts: 2080
|
| rajeessh wrote: |
| But in the call to Begin I am getting a MQError as MQRC_HCONN_ERROR AND Reason as 2018. |
| Code: |
public bool StartUnitOfWork(CMQRESULT mqResult)
{
m_qMgr.Begin();
mqResult.CompletionCode = m_qMgr.CompletionCode;
mqResult.ReasonCode = m_qMgr.ReasonCode;
mqResult.Result = (mqResult.CompletionCode != MQC.MQCC_FAILED);
return mqResult.Result;
} |
Can you be sure that m_qMgr has been connected (on this thread?) prior to this call? Seems to me as though m_qMgr has not been properly initialised before the app calls .Begin(). |
|
| Back to top |
|
|
| rajeessh |
| Posted: Tue Apr 11, 2006 5:15 am Post subject: |
|
|
Newbie
Joined: 03 May 2004
Posts: 8
|
I just told .NET and as far as my knowledge goes this doesn't seem to depend on .NET
My BeginTransaction effort fails with the above said exception and being a novice MQSeries programmer I am not able to figure it out exactly.
_________________
Srinivasan Rajesh
IT Consultant |
|
| Back to top |
|
|
| rajeessh |
| Posted: Tue Apr 11, 2006 5:17 am Post subject: |
|
|
Newbie
Joined: 03 May 2004
Posts: 8
|
Hi mvic master
I have called Connet before that and it replied as MQC.MQRC_ALREADY_CONNECTED which can be ignored.
The same way we use to do the code for our C++ MQSeries wrapper development
Pl let me know if I am wrong
Code for Connect is
public bool Connect(CMQRESULT mqResult)
{
if (m_szQMgr.Length == 0)
return false;
try
{
m_qMgr = new MQQueueManager(m_szQMgr);
m_qMgr.Connect();
mqResult.CompletionCode = m_qMgr.CompletionCode;
mqResult.ReasonCode = m_qMgr.ReasonCode;
if (m_qMgr.CompletionCode == MQC.MQCC_OK || m_qMgr.ReasonCode == MQC.MQRC_ALREADY_CONNECTED)
mqResult.Result = true;
else
mqResult.Result = false;
return mqResult.Result;
}
catch (MQException mqExcept)
{
if (mqExcept.ReasonCode == MQC.MQRC_ALREADY_CONNECTED)
mqResult.Result = true;
else
{
mqResult.Result = false;
throw mqExcept;
}
return mqResult.Result;
}
}
_________________
Srinivasan Rajesh
IT Consultant |
|
| Back to top |
|
|
| mvic |
| Posted: Tue Apr 11, 2006 6:05 am Post subject: |
|
|
Jedi
Joined: 09 Mar 2004
Posts: 2080
|
| Do you really want/need to call qmgr.begin()? What exactly are you trying to achieve with this system? |
|
| Back to top |
|
|
| questro |
| Posted: Tue Apr 11, 2006 6:37 am Post subject: |
|
|
Newbie
Joined: 07 Mar 2006
Posts: 9
Location: Magic Land
|
The behaviour you are experiencing is caused by the fact that you can only use the MQBEGIN verb (and therefor the Begin method on MQQueueManager objects) for queue manager connections that are not shared between threads (ie use MQCNO_HANDLE_SHARE_NONE).
By default, when the .NET MQQueueManager object connects to the queue manager it uses MQCNO_HANDLE_SHARE_BLOCK - ie shared between threads but blocking whilst another thread is using the connection - this is the case unless the application is running in a COM+ transaction environment, where the MQCNO_HANDLE_SHARE_NONE option is forced.
The 2018 error you're seeing (MQRC_HCONN_ERROR) is because the queue manager connection which you have created by creating an MQQueueManager object is connected with the MQCNO_HANDLE_SHARE_BLOCK option, ie the default outside of an MTS environment (the same behaviour would be observed if the connection was shared either BLOCK or NO_BLOCK)
The solution is to explicitly set the handle sharing option when creating your queue manager object - you can do this in a couple of ways, using either the MQQueueManager constructor that explicitly takes an Options parameter, or the MQQueueManager constructor that takes a hashtable and specify a hashtable entry with MQC.CONNECT_OPTIONS_PROPERTY and numeric value MQC.MQCNO_HANDLE_SHARE_NONE.
So...
1)
| Code: |
m_qMgr = new MQQueueManager(m_szQMgr, MQC.MQCNO_HANDLE_SHARE_NONE);
... |
or
2)
| Code: |
Hashtable opts = new Hashtable();
opts.Add(MQC.CONNECT_OPTIONS_PROPERTY, MQC.MQCNO_HANDLE_SHARE_NONE);
m_qMgr = new MQQueueManager(m_szQMgr, opts);
... |
The MQQueueManager object you end up with can only be used on that thread, the thread that created the object.
Be ready for the warning 2121 (MQRC_NO_EXTERNAL_PARTICIPANTS) if you haven't configured any additional resource managers to MQ - which in this configuration is acting as the transaction manager - if there are no external resource managers, MQ won't perform 2 phase commit because there is nothing else to co-ordinate with.
The more natural way to use 2-phase commit in the .NET framework is to use MSDTC. Make your application a COM+ application, MQ becomes a resource manager, the transaction is managed by MSDTC. MQ looks after registering with MSDTC and you commit / rollback your transactions with the ContextUtil.SetComplete and ContextUtil.SetAbort methods. |
|
| Back to top |
|
|
| Leigh Kendall |
| Posted: Tue Apr 11, 2006 10:35 am Post subject: |
|
|
Acolyte
Joined: 10 Apr 2003
Posts: 66
Location: Hartford, CT
|
rajessh -
If you're using .NET and just use COM+ with AutoComplete. This will allow you to add other resources besides just MQ to your distributed transaction as you need.
See the following Redbook for a complete discussion w/example code:
http://tinyurl.com/l9ga4
Check out Chapter 13.
HTH,
_________________
Leigh Kendall |
|
| Back to top |
|
|
| rajeessh |
| Posted: Tue Apr 11, 2006 8:38 pm Post subject: |
|
|
Newbie
Joined: 03 May 2004
Posts: 8
|
Hi questro
Thanks for your tips and as I did exactly what you told me and handled the warning it works.
When I did a Begin and Commit or Begin and Rollback message written in remote queue is held in transmit queues until I give a commit or rollback
On rollback all messages are cleared and on commit message is transmitted to the remote queue.
But if I write to a local queue then the message immediately appears in the local queue without giving commit or rollback.
Can the message appear with count in the queues before I give commit as the potential problem of other application reading the error is higher.
_________________
Srinivasan Rajesh
IT Consultant |
|
| Back to top |
|
|
| mvic |
| Posted: Wed Apr 12, 2006 12:50 am Post subject: |
|
|
Jedi
Joined: 09 Mar 2004
Posts: 2080
|
| rajeessh wrote: |
| Thanks for your tips and as I did exactly what you told me and handled the warning it works. |
I'm confused. Is qmgr.begin failing with 2121? If so, it has not worked. It has not started a global unit of work with another resource manager. Why are you calling qmgr.begin if you're allowing it to fail without worrying about it?
(Did I misinterpret you? - sorry if so) |
|
| Back to top |
|
|
| rajeessh |
| Posted: Wed Apr 12, 2006 1:06 am Post subject: |
|
|
Newbie
Joined: 03 May 2004
Posts: 8
|
I am currently testing only MQ Read and Writes
Later this interface is going to be used along with DB Commits
So it will change as two phase commit later.
This is just a piece of sample testing to be done on the interface from my side.
_________________
Srinivasan Rajesh
IT Consultant |
|
| Back to top |
|
|
| questro |
| Posted: Wed Apr 12, 2006 1:47 am Post subject: |
|
|
Newbie
Joined: 07 Mar 2006
Posts: 9
Location: Magic Land
|
| rajeessh wrote: |
But if I write to a local queue then the message immediately appears in the local queue without giving commit or rollback.
Can the message appear with count in the queues before I give commit as the potential problem of other application reading the error is higher. |
I think what you are asking is whether or not uncommitted messages show up in the message count - the answer is yes - if you try and get them they will be unavailable, but the queue depth will show them. |
|
| Back to top |
|
|
|
|
