| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
| commit |
« View previous topic :: View next topic » |
| Author |
Message
|
| alperb |
 Posted: Wed Oct 26, 2005 4:58 am Post subject: commit |
 |
|
Apprentice
Joined: 01 Jun 2004
Posts: 25
|
hi all,
we have an application sending and receiving messages to queues -nothing more complex- about 40-50 messages per second. Does the explicit commit lower the performance compared to auto-commit? Is commit in this context alike with flushing to a file? |
|
| Back to top |
|
 |
| jefflowrey |
| Posted: Wed Oct 26, 2005 5:01 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Never trust auto-commit.
Always commit as often as you can.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| Mr Butcher |
| Posted: Wed Oct 26, 2005 5:24 am Post subject: |
|
|
Padawan
Joined: 23 May 2005
Posts: 1716
|
depending on the platform there are also limits on uncomitted messages, e.g. "maximum number of uncomitted messages" in z/os. or if logfiles (or number of logfiles) are too small on windows / unix the uow may be rolled back because of a lack of logspace (circular logging).
data volume may change, so doing commits is recommended.
_________________
Regards, Butcher |
|
| Back to top |
|
|
| hopsala |
| Posted: Wed Oct 26, 2005 6:43 am Post subject: |
|
|
Guardian
Joined: 24 Sep 2004
Posts: 960
|
| Mr Butcher wrote: |
| depending on the platform there are also limits on uncomitted messages, e.g. "maximum number of uncomitted messages" in z/os. |
?
This applies to any platform - see crtmqm parameter "-x".
| jefflowrey wrote: |
| Always commit as often as you can. |
Again I wonder...?
There is no real difference between commiting every message by explicit issue of MQCMIT or using auto-commit; however, there is a huge difference between commiting every message or every, say, 10 messages - performance is far better if you don't commit every msg.
See Queue Depth above 15000 - Slow Performace and Question on queue design for high volumne for further info plus other threads on this site, and check out the performance documents support pacs. (p.s next time please use the search button before posting)
Note that you must design your program accordingly, i.e if you commit every 20 msgs, keep in mind that sometimes these messages will be rolled back, and so you must be able to recreate them. |
|
| Back to top |
|
|
| wschutz |
| Posted: Wed Oct 26, 2005 6:49 am Post subject: |
|
|
Jedi Knight
Joined: 02 Jun 2005
Posts: 3316
Location: IBM (retired)
|
What exactly do we mean by "auto-commit"?
_________________
-wayne |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Wed Oct 26, 2005 6:51 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
| hopsala wrote: |
| jefflowrey wrote: |
| Always commit as often as you can. |
Again I wonder...? |
It's better to suffer small application level performance degradation than to wonder where your messages are...
It's better to suffer small application level performance degredation than to fill up mq log space with uncomitted messages.
It's better to suffer small application level performance degredation than to rely on auto-commit and end up putting 10,000 messages in a single transaction.
It's better to be explicit in code about important business behavior than to rely on implicit behavior.
That said, it's better to use container managed transactions than bean managed transactions in a lot of J2EE cases.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| hopsala |
| Posted: Wed Oct 26, 2005 7:02 am Post subject: |
|
|
Guardian
Joined: 24 Sep 2004
Posts: 960
|
| wschutz wrote: |
| What exactly do we mean by "auto-commit"? |
I mean NO_SYNCPOINT - implicit mq commit every msg (which I believe is what alperb meant by "auto-commit")
| jefflowrey wrote: |
| It's better to... |
Good call, I agree that in most cases using syncpoints every so-and-so msgs adds complexity to code (thus maintenance etc) and is therefore not recommended in most cases; unless one must deal with huge throughputs, it will probably do more damage than good - a double edged sword, like so many WMQ design options...
And let it be known, I did not for a moment, nor will I ever, refer to commiting more than every 20 or so msgs; the performance benefit is a non-linear graph, over 20 or so it's just not worth it.
I was, however, answering what alperb asked about performance, which seemed appropriate 
| jefflowrey wrote: |
| It's better to be explicit in code about important business behavior than to rely on implicit behavior. |
This is the only point I find curious - why do you not trust implicit commit? It's the same like saying "never use MQPUT1", catch my drift? |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Wed Oct 26, 2005 7:06 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
| hopsala wrote: |
| jefflowrey wrote: |
| It's better to be explicit in code about important business behavior than to rely on implicit behavior. |
This is the only point I find curious - why do you not trust implicit commit? It's the same like saying "never use MQPUT1", catch my drift? |
I was assuming he meant "allow MQ to commit when I disconnect, rather than putting in an explicit COMMIT statement", rather than "don't use SYNCPOINT".
I don't view NO_SYNCPOINT as being "auto-commit", I view it as, umm, non-transactional.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| wschutz |
| Posted: Wed Oct 26, 2005 7:07 am Post subject: |
|
|
Jedi Knight
Joined: 02 Jun 2005
Posts: 3316
Location: IBM (retired)
|
NO_SYNCPOINT is dangerous with the MQ client... you can loose messages on a MQGET with it. An on the MQPUT side, if you get back the evil 2009, you're never certain whether the put worked or not.
_________________
-wayne |
|
| Back to top |
|
|
| hopsala |
| Posted: Wed Oct 26, 2005 7:13 am Post subject: |
|
|
Guardian
Joined: 24 Sep 2004
Posts: 960
|
| jefflowrey wrote: |
| I don't view NO_SYNCPOINT as being "auto-commit", I view it as, umm, non-transactional. |
Aha, but why? (I mean, except what wayne just said, which is a good point - but let's talk normal IPC server connection for a moment)
| wschutz wrote: |
| An on the MQPUT side, if you get back the evil 2009, you're never certain whether the put worked or not. |
Hm, I was not aware of this - So when one gets 2009 are you not assured that the message was not put to queue? Have you come across cases that you had a message on queue with 2009? And can you not also get 2009 on your MQCMIT, facing the same dilemma? |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Wed Oct 26, 2005 7:22 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
| hopsala wrote: |
| jefflowrey wrote: |
| I don't view NO_SYNCPOINT as being "auto-commit", I view it as, umm, non-transactional. |
Aha, but why? |
By definition, yes?
You can't commit a transaction if you haven't started one... and "NO_SYNCPOINT" means no transaction...
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| wschutz |
| Posted: Wed Oct 26, 2005 7:29 am Post subject: |
|
|
Jedi Knight
Joined: 02 Jun 2005
Posts: 3316
Location: IBM (retired)
|
Scenario 1:
1. Client does MQPUT NO_SYNC
2. MCA does MQPUT NO_SYNC on server, MQCC=OK (on behalf of client)
3. something cuases the connection to break
4. Client gets back 2009
5. Did it work?
Scenario 2:
1. Client does MQPUT NO_SYNC
2. MCA does MQPUT NO_SYNC on server, MQRC=Q_FULL (on behalf of client)
3. something cuases the connection to break
4. Client gets back 2009
5. Did it work?
Scenario 3:
1. Client does MQPUT SYNC
2. MCA does MQPUT SYNC on server, MQCC=OK (on behalf of client)
3. something cuases the connection to break
4. Client gets back 2009
5. Client knows that message will be rolled back since no CMIT done
Scenario 4:
1. Client does MQPUT SYNC
2. MCA does MQPUT SYNC on server, MQRC=Q_FULL (on behalf of client)
3. something cuases the connection to break
4. Client gets back 2009
5. Client knows that message will be rolled back since no CMIT done (well, actually, it failed, but client still is okay in assuming message isn't put)
Now, you can argue that the MQCMIT can also give back a 2009, and I'd agree, but the change of failure on an MQCMIT is a lot smaller than on an MQPUT (ie, no PUT_DISABLED, Q_FULL.. etc...)... of course, if you need it absolutely tight, then use an XA protocol 
_________________
-wayne |
|
| Back to top |
|
|
| hopsala |
| Posted: Wed Oct 26, 2005 11:45 am Post subject: |
|
|
Guardian
Joined: 24 Sep 2004
Posts: 960
|
| jefflowrey wrote: |
| You can't commit a transaction if you haven't started one... and "NO_SYNCPOINT" means no transaction... |
Just because the QM has started and ended the transaction for you, doesn't mean it's not there: NO_SYNCPOINT does not mean no transaction, it just means "transaction is commited immediately after it starts" (unless i'm gravely mistaken). Is this a terminology-oriented discussion and I haven't noticed? 
| wschutz wrote: |
| Now, you can argue that the MQCMIT can also give back a 2009, and I'd agree, but the change of failure on an MQCMIT is a lot smaller than on an MQPUT (ie, no PUT_DISABLED, Q_FULL.. etc...)... |
That's not really relevent here - All these error scenarios will return a normal RC stating that no message was put to queue, so no problem with data consistency. I was asking specifically about 2009 - The scenarios you sketched I know in theory, but I found no documentation about whether there's a chance you get 2009 while commit was successful, and more importantly -I have never seen it happen; in my experience, the message was always rolled back. Have you encountered this?
Regardless, if indeed there's a chance of discrepancies due to 2009, I see no difference between getting it in your MQCMIT or MQPUT. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Wed Oct 26, 2005 1:29 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| hopsala wrote: |
whether there's a chance you get 2009 while commit was successful, and more importantly -I have never seen it happen; in my experience, the message was always rolled back. Have you encountered this?
Regardless, if indeed there's a chance of discrepancies due to 2009, I see no difference between getting it in your MQCMIT or MQPUT. |
Put under syncpoint, then issue the MQCMIT. The MQCMIT executes succesfully. The message is commited. But as the QM goes to send the good RC for the MQCMIT to the app, the connection is lost. The MQRC=00 for MQCMIT is never delivered to the app. Eventually the app gets a 2009 MQRC.
Now what? 
It worked, the message is on the queue, committed, but you are staring at a 2009 error. What are you gonna do?
Obviously the oppourtunity for dropped connections is there for both client apps and bindings mode apps, but its more likely for client apps due to the network being involved. Yes, a local app in bindings mode can get a 2009!
I agree that you are just as likely to get a 2009 on a MQPUT as you are on a MQCMIT. But at least with the 2009 MQPUT, you know the message either never made it to the q, or if it did, it is there uncommited, and will be rolled back.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| hopsala |
| Posted: Wed Oct 26, 2005 6:55 pm Post subject: |
|
|
Guardian
Joined: 24 Sep 2004
Posts: 960
|
| PeterPotkay wrote: |
Yes, a local app in bindings mode can get a 2009!
I agree that you are just as likely to get a 2009 on a MQPUT as you are on a MQCMIT. |
This is the point I was trying to make, thanks for phrasing it so much more clearly than I did 
| PeterPotkay wrote: |
| But at least with the 2009 MQPUT, you know the message either never made it to the q, or if it did, it is there uncommited, and will be rolled back. |
Well, that's what I thought as well, but wayne here claims otherwise (unless I misunderstood):
| wschutz wrote: |
| NO_SYNCPOINT is dangerous with the MQ client... you can loose messages on a MQGET with it. An on the MQPUT side, if you get back the evil 2009, you're never certain whether the put worked or not. |
See? |
|
| Back to top |
|
|
|
|
|
  |
Goto page 1, 2 Next |
Page 1 of 2 |
|
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
|
|
|
|
