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 IndexIBM MQ API SupportWMQ 7 Client - Assured Delivery?

Post new topicReply to topic Goto page Previous  1, 2, 3, 4  Next
WMQ 7 Client - Assured Delivery? View previous topic :: View next topic
Author Message
bruce2359
PostPosted: Wed Mar 30, 2011 4:56 am Post subject: Reply with quote

Poobah

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

The APG/APR leave me uncertain. One or the other talks about 'if the application terminates abnormally...'.

I gather that an application MQDISConnecting without commit is as a 'normal' task end. Does mq software see as abnormal an application that has issued an MQCMIT, AND the resources have been committed, but disappears (2009) before the app can receive the CC/RC? If so, then backout would be the expected response from mq.
_________________
Random numbers are far too important to be left to chance.
Back to top
View user's profile Send private message
PeterPotkay
PostPosted: Wed Mar 30, 2011 5:23 pm Post subject: Reply with quote

Jedi Council

Joined: 15 May 2001
Posts: 7334

mvic wrote:
PeterPotkay wrote:
Whether it gets a 2009 on its MQCMIT in the case of a single phase, or the transaction manager gets it in a 2 phase, your app or the transaction manager has the same dilemma - did the message get committed to the queue or not, right?

Well, not really, IMHO.

In 2PC there are post-crash recovery actions that are taken, so the app has an even more solid safeguard than 1PC (which is already solid enough for most people, of course).

In a 2PC post-crash scenario, the TM asks the RMs, "what transactions do you think are still pending". The RMs tell the TM, and the TM then informs the RMs of the proper outcome, which it has of course remembered in its logs.


This extra reconciliation takes place if the TM gets a 2009? Is it documented anywhere? Is this type of processing available for a single phase app that gets a 2009 on an MQCMIT??
_________________
Peter Potkay
Keep Calm and MQ On
Back to top
View user's profile Send private message
bruce2359
PostPosted: Wed Mar 30, 2011 5:46 pm Post subject: Reply with quote

Poobah

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

And, what constitutes an abnormal application termination that would cause an automatic MQBACK? Does failure of the app to successfully acquire the CC/RC constitute an abnormal termination?

Anyone? Anyone? Bueller? Bueller?

What we need here is a tool that let's us step through mqi calls one-by-one. After the MQCMIT, but before the CC/RC are returned, kill the process, and see what happens.
_________________
Random numbers are far too important to be left to chance.
Back to top
View user's profile Send private message
mvic
PostPosted: Thu Mar 31, 2011 2:12 am Post subject: Reply with quote

Padawan

Joined: 09 Mar 2004
Posts: 1981

PeterPotkay wrote:
This extra reconciliation takes place if the TM gets a 2009? Is it documented anywhere?

No, 2009 is an MQI reason code. The TM communicates with an RM through XA calls, and upon losing connectivity to an RM, it will receive a bad rc from (say) the xa_commit function. Details are in the XA Specification.

Quote:
Is this type of processing available for a single phase app that gets a 2009 on an MQCMIT??

No. With single phase, you send your request, and you get your response. If you crash, or your link crashes, before your response can be received, then there is no way, through that link, to be able to find out the outcome. (Because the link is now broken).

This is single-phase commit. I can't see how a single-phase commit in any system can improve on this. The way to improve is to have a second phase, managed either by the product you're using, or by your own application (eg. before you do something, record somewhere that you're going to do it, giving you the possibility later to come back and check whether it was done).
Back to top
View user's profile Send private message
sunny_30
PostPosted: Thu Mar 31, 2011 7:34 am Post subject: Reply with quote

Master

Joined: 03 Oct 2005
Posts: 252

This is what i understood from the discussion so far:
Im not a MQ expert.. So, please correct me if Im wrong.

MQserver-binding-conn + XA = 2PC
MQserver-binding-conn w/o XA = 1PC
MQclient -> always 1PC, XA not possible
MQtxClient w/o XA = 1PC
MQtxClient + XA = 2PC
2PCs provide 'once-only' assured messaging (if msg set to persistent)
1PCs dont provide assurity as they cannot support XA
MQCMIT call possible with MQclient, but doesnt help as XA not an option
Only XA supports MQBACK option
Back to top
View user's profile Send private message
mvic
PostPosted: Thu Mar 31, 2011 8:05 am Post subject: Reply with quote

Padawan

Joined: 09 Mar 2004
Posts: 1981

1 phase commit updates one resource.

2 phase commit involves updating a second (or third, or fourth...) resource manager inside each transaction. It is significantly more expensive in terms of performance, purchase cost, install and admin. But if that extra cost is justified in your opinion, that's fine.

Terms like "guarantee" and "assured" are just english words, with no technical weight in the software world. There are no guarantees, because systems can fail. Any system can fail. For example, what guarantee is there in your system's power supply?

Quote:
Only XA supports MQBACK option

This is incorrect. MQBACK is possible for any transaction in which MQ is the transaction manager.

Hope this helps
Back to top
View user's profile Send private message
PeterPotkay
PostPosted: Thu Mar 31, 2011 1:34 pm Post subject: Reply with quote

Jedi Council

Joined: 15 May 2001
Posts: 7334

mvic wrote:
PeterPotkay wrote:
This extra reconciliation takes place if the TM gets a 2009? Is it documented anywhere?

No, 2009 is an MQI reason code. The TM communicates with an RM through XA calls, and upon losing connectivity to an RM, it will receive a bad rc from (say) the xa_commit function. Details are in the XA Specification.


And can't the TM lose its connection with a RM during a commit call (or whatever the underlying call the equates to a commit)? Isn't getting a bad RC from the xa_commit function the same dilemma as a 2009 for a single phase app doing an MQCMIT?
_________________
Peter Potkay
Keep Calm and MQ On
Back to top
View user's profile Send private message
mvic
PostPosted: Thu Mar 31, 2011 3:11 pm Post subject: Reply with quote

Padawan

Joined: 09 Mar 2004
Posts: 1981

PeterPotkay wrote:
And can't the TM lose its connection with a RM during a commit call (or whatever the underlying call the equates to a commit)?

Yes.

Quote:
Isn't getting a bad RC from the xa_commit function the same dilemma as a 2009 for a single phase app doing an MQCMIT?

I understand why you might say this, but I think the answer is still No.

Because the xa_commit is the second of two phases, and so can be re-queried and repeated after a broken link.

Firstly it is still possible for the app or its link to fail before getting its "ok" response from the server. That much is inevitable.

But 2PC offers post-crash roll-forwards that 1PC cannot offer.

In 2PC, in order to get to xa_commit (2nd phase) you have been through a successful xa_prepare (1st phase) to ALL participating RMs. So before calling xa_commit to the first RM, the TM knows that it, and all the RMs in that transaction, have stored a permanent log of their work under that transaction, and are able to roll it forwards (ie. finally commit). After that point, if needed, the permanent log information can be queried after a crash at this moment, and used to continue rolling forwards, supposing that is what the app commanded the TM to do.
Back to top
View user's profile Send private message
PeterPotkay
PostPosted: Fri Apr 01, 2011 7:23 am Post subject: Reply with quote

Jedi Council

Joined: 15 May 2001
Posts: 7334

mvic wrote:
After that point, if needed, the permanent log information can be queried after a crash at this moment, and used to continue rolling forwards, supposing that is what the app commanded the TM to do.


Right on. I guess I'm thinking "Wouldn't it be nice if a single phase app had the ability to talk with the QM and say ' Hey, remember that MQPUT I just did? Welp, I tried to commit it, and I don't know if it worked or not. Talk to me.' "
_________________
Peter Potkay
Keep Calm and MQ On
Back to top
View user's profile Send private message
bruce2359
PostPosted: Fri Apr 01, 2011 7:29 am Post subject: Reply with quote

Poobah

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

I've been searching through the WMQ doc looking for LUWID, and finding only channel-related LUWID.

Whether a single-phase or two-phase UofW, I suppose WMQ creates a UofW id for local- and global-uofw's where the app coordinates; but it doesn't seem to offer that LUWID via the MQI.
_________________
Random numbers are far too important to be left to chance.
Back to top
View user's profile Send private message
mvic
PostPosted: Fri Apr 01, 2011 7:52 am Post subject: Reply with quote

Padawan

Joined: 09 Mar 2004
Posts: 1981

PeterPotkay wrote:
Hey, remember that MQPUT I just did? Welp, I tried to commit it, and I don't know if it worked or not. Talk to me.' "

Why, so it can pick up with what it was doing? Can you give me an example - it is unclear to me what scenario you're thinking of, sorry.

Anyway, with 2PC you can get your app to do something like this, because in each transaction your app can have put a change to some "last good piece of work" state held under that transaction by a participating RM. If your work was good, then the state in the other RM will be updated. If it wasn't good, the state will not be updated.

One slight problem is that it is possible that the app doesn't know after a broken link whether the TM and/or RMs still has its last transaction held in-doubt between them. For example, if the failure was wider than just the app->server connection, the transaction could still be in progress, or could be subject to some further delay or failure.

(Although I believe it should be possible for a TM to offer an API call for the app to find out, but I don't know of any with MQ.)
Back to top
View user's profile Send private message
mvic
PostPosted: Fri Apr 01, 2011 7:54 am Post subject: Reply with quote

Padawan

Joined: 09 Mar 2004
Posts: 1981

Quote:
... finding only channel-related LUWID

There is a simplified 2-phase commit in message channels. The UOW is in-doubt until the sender hears back from the receiver that the UOW was successful. That's what the LUWID is for, as I understand it.
Back to top
View user's profile Send private message
bruce2359
PostPosted: Fri Apr 01, 2011 8:01 am Post subject: Reply with quote

Poobah

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

Quote:
If your work was good, then the state in the other RM will be updated. If it wasn't good, the state will not be updated.

'Assured delivery' seems only to apply to the resources updated (or not) by the app; but does not include the app itself in the assured delivery.

Thus, we can only deduce that either the resources were committed or backed out; but the app can't be sure which in this oddity of app failure after the commit call.
_________________
Random numbers are far too important to be left to chance.
Back to top
View user's profile Send private message
mvic
PostPosted: Fri Apr 01, 2011 8:11 am Post subject: Reply with quote

Padawan

Joined: 09 Mar 2004
Posts: 1981

bruce2359 wrote:
'Assured delivery' seems only to apply to...

I don't see this phrase as having any specific technical meaning in the software world. Any part of a computer system can fail, and that's life. You measure risk, you mitigate risk. You compose your systems from parts made by competent engineers (hardware, software). You (or your vendors on your behalf) introduce duplication, logging etc. to reduce single points of failure... all of that. But you'll never reduce the risk to zero. You just have to decide how much cost is possible and/or appropriate to use in reducing risk.
Back to top
View user's profile Send private message
bruce2359
PostPosted: Fri Apr 01, 2011 8:23 am Post subject: Reply with quote

Poobah

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

Quote:
'Assured delivery' seems only to apply to...

My point here is that assured delivery is generally misunderstood.

Other than that, completely.

To improve reliability, applications should (must?) be developed to tolerate and deal with duplication and/or loss of data.
_________________
Random numbers are far too important to be left to chance.
Back to top
View user's profile Send private message
Display posts from previous:
Post new topicReply to topic Goto page Previous  1, 2, 3, 4  Next Page 3 of 4

MQSeries.net Forum IndexIBM MQ API SupportWMQ 7 Client - Assured Delivery?
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.