ASG
IBM
Zystems
Cressida
Icon
Netflexity
 
  MQSeries.net
Search  Search       Tech Exchange      Education      Certifications      Library      Info Center      SupportPacs      LinkedIn  Search  Search                                                                   FAQ  FAQ   Usergroups  Usergroups
 
Register  ::  Log in Log in to check your private messages
 
RSS Feed - WebSphere MQ Support RSS Feed - Message Broker Support

MQSeries.net Forum Index » Multiphase Commit » MQSeries 7.5 and 7.1.0.6 client with C# 2 phase commit help

Post new topic  This topic is locked: you cannot edit posts or make replies. Goto page 1, 2  Next
 MQSeries 7.5 and 7.1.0.6 client with C# 2 phase commit help « View previous topic :: View next topic » 
Author Message
davis_mc
PostPosted: Fri Nov 20, 2015 6:18 pm    Post subject: MQSeries 7.5 and 7.1.0.6 client with C# 2 phase commit help Reply with quote

Newbie

Joined: 20 Nov 2015
Posts: 8

Hi,

I am having a strange issue and I'm not too sure where to go with this.

First in my code for the connection to MQ I am using

Code:

queueProperties = new Hashtable();
queueProperties[MQC.HOST_NAME_PROPERTY] = host;
queueProperties[MQC.PORT_PROPERTY] = port;
queueProperties[MQC.CHANNEL_PROPERTY] = channel;
queueProperties.Add(MQC.TRANSPORT_PROPERTY, MQC.TRANSPORT_MQSERIES_MANAGED);


I am using the general idea with TransactionScope.

Code:
using (TransactionScope scope = new TransactionScope(TransactionScopeOption.Required, TimeSpan.MaxValue))
{


and the Put of like bytes for the message is under another transaction scope:

Code:

using (TransactionScope scopeMQByte = new TransactionScope(TransactionScopeOption.Required))
                {
                    queue = queueManager.AccessQueue(queueName, MQC.MQOO_OUTPUT + MQC.MQOO_FAIL_IF_QUIESCING);
                    queueMessage = new MQMessage();
                    queueMessage.Write(message);
                    queueMessage.Format = MQC.MQFMT_NONE;
                    MQPutMessageOptions pmo = new MQPutMessageOptions();
                    pmo.Options = MQC.MQPMO_SYNCPOINT + MQC.MQPMO_FAIL_IF_QUIESCING;
                    queue.Put(queueMessage, pmo);
                    scopeMQByte.Complete();
                    return true;
                }


So it basically happens like this let's say I am looping through and doing 4 puts:

Using First TransactionScope
---Loop
-----Call the PUT separate method
---------Second TransactionScope
-------------Send Put Msg to MQ
-------------Commt on the second scope
-----Perform database updates
-----Commit on the first (parent scope)
---EndLoop
end using



Now, with the MQC.TRANSPORT_MQSERIES_MANAGED done...

When I execute this it will put the message in the queue. It will not show up in the browse of the message from MQExplorer - that's understandable.

When it attempts to perform the DB updates it fails on the open with messages that seem to indicate there may be MSDTC issues but why on the DB? (especially when it works just fine as noted below).

Now, the exact same code and same process but with the MQC.TRANSPORT_MQSERIES_MANAGED NOT DONE.

Going through the exact same process of as described above:

Using First TransactionScope
---Loop
-----Call the PUT separate method
---------Second TransactionScope
-------------Send Put Msg to MQ
-------------Commt on the second scope
-----Perform database updates
-----Commit on the first (parent scope)
---EndLoop
end using

Now, it functions just fine. Put's the messages in the queue and updates the DB. But let's say that on the 3rd of the 4 puts it puts the 3 message in the queue but fails on the "Perform database updates" what I see that all DB transactions for the first 2 iterations on rolled back.

But and this is where the problem is...the MQ queue rolls back 1 or sometimes 2 messages but there is always something left in the queue (1 or 2 message) instead of rolling back all 3.

Why would it do this and what can I (or even can I) get all 3 in the queue to rollback?

Any info on this would be greatly appreciated.

Thanks
Back to top
View user's profile Send private message
fjb_saper
PostPosted: Sat Nov 21, 2015 9:30 am    Post subject: Reply with quote

Grand High Poobah

Joined: 18 Nov 2003
Posts: 20696
Location: LI,NY

Did you set up MSDTC?
Did you set it up to handle MQ?
_________________
MQ & Broker admin
Back to top
View user's profile Send private message Send e-mail
davis_mc
PostPosted: Sat Nov 21, 2015 10:58 am    Post subject: Reply with quote

Newbie

Joined: 20 Nov 2015
Posts: 8

I used the default settings on both the DB and the server I am executing from. I cannot do the MQ because that is a third-party.
Back to top
View user's profile Send private message
bruce2359
PostPosted: Sat Nov 21, 2015 1:09 pm    Post subject: Reply with quote

Poobah

Joined: 05 Jan 2008
Posts: 9394
Location: US: west coast, almost. Otherwise, enroute.

Search google for mq MSDTC setup. Things must be configured.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live.
Back to top
View user's profile Send private message
davis_mc
PostPosted: Sat Nov 21, 2015 2:25 pm    Post subject: Reply with quote

Newbie

Joined: 20 Nov 2015
Posts: 8

But what type of options would I need put in the MSDTC on both machines? (i.e. the PC running it and the DBMS PC)?

Then, if the MQ is third party what if they are not even using MSDTC. They might have a unique distribution transaction controller where is may not be MSDTC.

I have like the default setting of Network Access DTC Access, Allow Inbound and Allow Outbound, Mutual Authentication Required, Enable XA Transactions and Enable SNA LU 6.2 Transactions as well as DTC Logon Account of the default of: NT AUTHORITY\NetworkServices.

Even so, without it why would it be working, in some cases, on the second type but not the first?


[/img]
Back to top
View user's profile Send private message
bruce2359
PostPosted: Sat Nov 21, 2015 5:19 pm    Post subject: Reply with quote

Poobah

Joined: 05 Jan 2008
Posts: 9394
Location: US: west coast, almost. Otherwise, enroute.

In a unit-of-work (transaction), either all of the changes are committed OR none of them are committed.

Your app can always do sql calls and mq calls, but if you want them to be a unit-of-work, then you must configure the resource managers (MQ and your DB) and the transaction coordinator to work as a team.

What configuration documentation did you follow to build this?
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live.
Back to top
View user's profile Send private message
fjb_saper
PostPosted: Sat Nov 21, 2015 8:58 pm    Post subject: Reply with quote

Grand High Poobah

Joined: 18 Nov 2003
Posts: 20696
Location: LI,NY

Hint you must also configure MSDTC on the MQ server, and grant the MSDTC user the relevant access to MQ.

And please check the infocenter, depending on the Version of MQ you may not be able to do a multiphase commit with a managed connection ...
_________________
MQ & Broker admin
Back to top
View user's profile Send private message Send e-mail
davis_mc
PostPosted: Sun Nov 22, 2015 6:43 am    Post subject: Reply with quote

Newbie

Joined: 20 Nov 2015
Posts: 8

fjb_saper, are you saying MSDTC equivalent because what is the third-party is not MS centric?

bruce_2359, the IBQ .NET samples that come with the client reference the transaction scope use. But for the 2 phase commit nested scopes using the DB and the another object use (i.e. non-DB, like NTFS) were from the MS websites

But what I don't understand it why on the second aspect that I mentioned where the MQC.TRANSPORT_MQSERIES_MANAGED IS NOT DONE, that it works seemingly variably in nature. (i.e. 1 or 2 messages get rollback on the MQ queue), yet the DB is just fine and rollsback just fine. Especially, especially is the third-party in unaware so the MSDTC (or equivalent) wasn't done nor might we even be able to. I'm wondering if this is the ONLY option we have to work with.

And WHY WHEN I DO USE MQC.TRANSPORT_MQSERIES_MANAGED, the MSDTC issues are DB (not MQ) issues with the OPEN.
Back to top
View user's profile Send private message
bruce2359
PostPosted: Sun Nov 22, 2015 7:18 am    Post subject: Reply with quote

Poobah

Joined: 05 Jan 2008
Posts: 9394
Location: US: west coast, almost. Otherwise, enroute.

An MQ local unit-of-work is one in which only MQ updates are committed/backed out - using MQCMIT/MQBACK (or equivalent) calls.

An MQ global unit-of-work is a UOW that encompasses both MQ gets/puts and DB updates. The MQBEGIN (or equivalent) call is used to indicate that the resources of multiple resource managers will be committed or backed out as a u-of-w. A transaction manager application provides the commit/backout calls to complete/discard the global u-of-w.

Have you configured MQ queue-manager so that it can participate in a global unit-of work? Have you configured your DB? Have you installed the MQ Extended Transnational Client software? Have you configured your transaction manager? If the answer to any of these is 'no' then your application will not behave as you want it to.

Just because vendor-provided documentation tells you (promises) that such-and-such will do something, doesn't mean that there are not prerequisites that must be in place first.

Other than compiling and executing this application, what else (configuration) have you done?
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live.
Back to top
View user's profile Send private message
davis_mc
PostPosted: Sun Nov 22, 2015 7:42 am    Post subject: Reply with quote

Newbie

Joined: 20 Nov 2015
Posts: 8

So, even the one from IBM from the client as a sample MQ is not accurate? That one does NOT use the MQCOMIT/MQBACK. It uses the TransactionScope and a Commit from the transactionscope object. Especially since I installed a local MQ Series 7.5 and ran that app with the settings for my local MQ and it worked as stated. BUT it didn't have the DB obviously. So, in that sense both vendors MQ and IBM we in the right. But again, obviously a DB was not involved.

How would I configure my local MQ to participate in the global UOW? The DB is SQL Server and that is done via MSDTC. (Again, the fact that it's working when I do not use MQC.TRANSPORT_MQSERIES_MANAGED being that the DB is not local would indicate that it is able to function in a global UOW, right?)

However, I'm not sure if I will be able to get that local. MSDTC do not have many options and my machine is on one domain and the DB is on another. So the DTC Login options would/could be an issue. Especially, for another application that doesn't use MQ is in another domain.
Back to top
View user's profile Send private message
bruce2359
PostPosted: Sun Nov 22, 2015 8:16 am    Post subject: Reply with quote

Poobah

Joined: 05 Jan 2008
Posts: 9394
Location: US: west coast, almost. Otherwise, enroute.

davis_mc wrote:
So, even the one from IBM from the client as a sample MQ is not accurate?

I'm not sure what 'the one' is, but nearly all applications I've encountered, including those from vendors, describe what the application will do - presuming that you have done the prerequisite setup.

As a simple example, you can't expect to write and run a C program without first installing a C compiler. You can't use the MQI calls if you haven't first installed MQ. You can't do a two-phase commit without first having done the prerequisite installation/configuration to support it.


davis_mc wrote:
That one does NOT use the MQCOMIT/MQBACK. It uses the TransactionScope and a Commit from the transactionscope object.

TransactionScope is an abstraction of the MQI primitives. If you were to run an MQ trace, you wouldn't see your C code; rather, you would see the MQI calls the abstraction created for you.

davis_mc wrote:
But again, obviously a DB was not involved.

So, the u-of-w was a local u-of-w.

davis_mc wrote:
How would I configure my local MQ to participate in the global UOW?

I suspect that you will need the Extended Transactional Client, and the appropriate .ini file configuration. Research MS documentation, your DB documentation, and MQ documentation. Are you a sysadmin? If not, contact your sysadmin for help.

Or, you can wait a bit see if someone comes along with more guidance
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live.
Back to top
View user's profile Send private message
fjb_saper
PostPosted: Sun Nov 22, 2015 12:27 pm    Post subject: Reply with quote

Grand High Poobah

Joined: 18 Nov 2003
Posts: 20696
Location: LI,NY

fjb_saper wrote:
Hint you must also configure MSDTC on the MQ server, and grant the MSDTC user the relevant access to MQ, if the MQ server is on Windows...

And please check the infocenter, depending on the Version of MQ you may not be able to do a multiphase commit with a managed connection ...


If the MQ server is on Windows, at a minimum you need to configure the MSDTC client on the MQ server box. The MSDTC may use a proxy user (NT Network) and that user must be authorized for the MQ operations.
_________________
MQ & Broker admin
Back to top
View user's profile Send private message Send e-mail
davis_mc
PostPosted: Sun Nov 22, 2015 1:40 pm    Post subject: Reply with quote

Newbie

Joined: 20 Nov 2015
Posts: 8

bruce2359, Ok not I am thoroughly confused. Extended Transaction Client? Are you aware of what IBM did since 7.0? You need not the Extended Transaction Client any longer as it's in 7.0+ client and I'm using the 7.1.0.6. By the way, I am using C# .NET code. And by the way, I did contact our DBA which is well versed in the MSDTC aspects with SQL Server and it appeared as I was on the right track.

fjb_saper, good point on the proxy, "...and that user must be authorized for the MQ operations". I will check in on that and check InfoCenter. My understanding that that the version I am using the 7.5 MQ Server that I did locally and the third-party is using 7.0+ that I know should be covered there. The client I am using is 7.1.0.6 so that should be covered as well. But I will double check on the infocenter.

Right now, I see nothing and am hearing nothing that I am doing incorrectly, especially with the versions of MQ I am doing, except for having the third-party situation. And if we can have them engage in the transaction aspect well, then there is nothing we can really do for a multi-phase commit.

One things I still do not understand though is why on the other aspect where I am NOT using the MQC.TRANSPORT_MQSERIES_MANAGED would it be partially working. Complete DB and only part of MQ??
Back to top
View user's profile Send private message
bruce2359
PostPosted: Sun Nov 22, 2015 2:59 pm    Post subject: Reply with quote

Poobah

Joined: 05 Jan 2008
Posts: 9394
Location: US: west coast, almost. Otherwise, enroute.

davis_mc wrote:
bruce2359, Ok not I am thoroughly confused. Extended Transaction Client? Are you aware of what IBM did since 7.0? You need not the Extended Transaction Client any longer as it's in 7.0+ client and I'm using the 7.1.0.6.

I will pardon the somewhat snotty tone of your post.

Yes, I'm aware that the ETC is now included in the IMQ base distribution. Did you or your MQ sysadmin configure ETC to meet your needs?
davis_mc wrote:
By the way, I am using C# .NET code. And by the way, I did contact our DBA which is well versed in the MSDTC aspects with SQL Server and it appeared as I was on the right track.

Yes, you are on the right track. The IMQ ETC and other IMQ things need to be configured. The IMQ product as-shipped from the factory does not come pre-configured for your intended use of MSDTC or DBs. Did you, as I asked, contact the MQ system administrator?

davis_mc wrote:
Right now, I see nothing and am hearing nothing that I am doing incorrectly...

Your expectations do not match reality here. There are things that need configuration by trained technical folks.

davis_mc wrote:
One things I still do not understand though is why ... would it be partially working. Complete DB and only part of MQ??

It's only partially working because it is only partially configured.

Apologies if you don't like the questions and answers you being offered here. It's free help. Most of us posting here are employed, while others are MQ consultants.

For clarity: There are configurations that must be made to your queue-manager for it to be able to participate in a global unit-of-work. There are configurations that must be made to your DB. There are configurations that must be made to MSDTC.

I'd expect (hope) IMQ to capture some useful error/diagnostic information when you encounter the problem. Are there any related errors logged in the IMQ error file AMQERR01 for this queue-manager? Or in the IMQ installation AMQERR01 file? Any FDCs created?
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live.
Back to top
View user's profile Send private message
davis_mc
PostPosted: Sun Nov 22, 2015 3:47 pm    Post subject: Reply with quote

Newbie

Joined: 20 Nov 2015
Posts: 8

Bruce, its not spotty. It was a reality question. Please discontinue any response on this thread.. Your information and attempted help, athough appreciated has not been helpful. "Passing the buck" is not always a good solution as anybody seasoned person would know.

With respect thanks.
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic  This topic is locked: you cannot edit posts or make replies. Goto page 1, 2  Next Page 1 of 2

MQSeries.net Forum Index » Multiphase Commit » MQSeries 7.5 and 7.1.0.6 client with C# 2 phase commit help
Jump to:  



You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
Protected by Anti-Spam ACP
 
 


Theme by Dustin Baccetti
Powered by phpBB © 2001, 2002 phpBB Group

Copyright © MQSeries.net. All rights reserved.