| Author |
Message
|
| strom |
 Posted: Wed Apr 09, 2008 10:21 pm Post subject: giving syncpoint after another syncpoint without commit ... |
 |
|
Novice
Joined: 09 Apr 2008
Posts: 11
|
Hi all ,
I am new to all this ,
I had a doubt ...
I sort of have a loop which posts messages in MQ ( transaction wise) in which i
1) putmessageoptions is set having MQC.MQPMO_SYNCPOINT enabled ....
2) put message in MQ
3) i dont commit this message
what will happen when i come in loop next ?...
will the previous message been commited or is it lost ?...
or will it be still not available to the other application which tries to get it from the MQ ..
( Using Java )
This is first time i am posting ...
 |
|
| Back to top |
|
 |
| PeterPotkay |
| Posted: Wed Apr 09, 2008 10:38 pm Post subject: Re: giving syncpoint after another syncpoint without commit |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| strom wrote: |
what will happen when i come in loop next ?...
|
whatever your next line of code is
| strom wrote: |
will the previous message been commited or is it lost ?...
|
not commited, not lost.
| strom wrote: |
or will it be still not available to the other application which tries to get it from the MQ ..
|
You got it. Eventually you have to MQCMIT or MQBACK.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Wed Apr 09, 2008 10:39 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
you need a step 2.1
Check Status of MQPUT call to make sure it worked
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| strom |
| Posted: Wed Apr 09, 2008 10:53 pm Post subject: |
|
|
Novice
Joined: 09 Apr 2008
Posts: 11
|
PeterPotkay wrote :
| Quote: |
| whatever your next line of code is |
| Quote: |
| not commited, not lost. |
that means
a) Till i dont commit , the messages will not be visible to the other application ?...
b) That all the messages in put in the MQ with this logic not visible at all ?..
c) will adding step 3) commit solve the problem ?.... |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Wed Apr 09, 2008 10:59 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
a and b, yes.
c, yes.
Why are you holding the message back with a syncpoint? Do you not want the app to get it right away? Are you doing some other work first that you want to get done before the other app can eat your message? If there is no reason to hold it back, if you want the app to get that messages as soon as you MQPUT it, just put it without syncpoint.
If you need to put a lot of messages and performance is important and the messages are persistent, it will perform better if you put x messages under syncpoint and only MQCMIT every x messages (instead of putting and committing for every message). Check the MQRC after every MQ API call!!!
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| strom |
| Posted: Wed Apr 09, 2008 11:17 pm Post subject: |
|
|
Novice
Joined: 09 Apr 2008
Posts: 11
|
1) Each message that is posted in the loop is a different transaction ..
it need not wait for other message to get committed ...
2) actually the logic i have said belongs to a code i am analysing
a) the other application seems to pick up the messages from the MQ even the first application just puts messge in MQ with setting syncpoint each time it put message .....
b) no commit is done by first application when its puts message ( logic i have posted above ) .... |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Thu Apr 10, 2008 1:47 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
commits can be done when a disconnect occurs.
That is, in some cases, issuing MQDISC will do a commmit
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| strom |
| Posted: Thu Apr 10, 2008 1:57 am Post subject: |
|
|
Novice
Joined: 09 Apr 2008
Posts: 11
|
jefflowrey wrote
| Quote: |
| commits can be done when a disconnect occurs. |
are you saying that all messages are commited by default when one closes a connection to a queue ? or a queue manager ?...
code closes the queue , then the Queue manager and then disconnects from it ... |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Apr 10, 2008 2:03 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| strom wrote: |
| are you saying that all messages are commited by default when one closes a connection to a queue ? or a queue manager ?... |
Pedantically, you don't connect to a queue, you open it. The connection is to the queue manager, and it's this that the MQDISC closes.
Disconnecting can cause an implicit commit, but it's seldom relied on for reason discussed further up the post. The APG will give more details on this.
Personally, I prefer more control over what messages are in what unit of work, and use explicit commits. Other views may be equally valid.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Thu Apr 10, 2008 2:19 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| Vitor wrote: |
Disconnecting can cause an implicit commit, but it's seldom relied on for reason discussed further up the post. The APG will give more details on this.
Personally, I prefer more control over what messages are in what unit of work, and use explicit commits. Other views may be equally valid. |
 Make sure you read the programmer's manuals. The implicit behavior for commit may be different by platform. There is no reason to rely on an implicit behavior that might change with a next release.
ALWAYS specify your commit/rollback points explicitly when working with UOWs.
Enjoy 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Thu Apr 10, 2008 2:28 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
I wasn't advocating practice, I was attempting to explain the evidence - "Messages are put in syncpoint, never committed, but still processed by the receiving app".
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| strom |
| Posted: Thu Apr 10, 2008 2:29 am Post subject: |
|
|
Novice
Joined: 09 Apr 2008
Posts: 11
|
Vitor wrote
| Quote: |
| Disconnecting can cause an implicit commit |
So the reason for the code to commit data without an explicit commit is that Disconnecting can cause an implicit commit ? ...
does it happen most of times ?.....
code picks up few transactions that get posted in real time ..
puts them in MQ ...
and closes queue , closes queue manager and disconnects from it .
that could explain how the message gets to the other application |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Apr 10, 2008 2:34 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| strom wrote: |
| does it happen most of times ?..... |
It depends on a number of factors. Check the APG.
| strom wrote: |
| that could explain how the message gets to the other application |
It could. If it's a good way of doing it is a less clear cut question.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| strom |
| Posted: Thu Apr 10, 2008 2:37 am Post subject: |
|
|
Novice
Joined: 09 Apr 2008
Posts: 11
|
yeah i get the point ...
i would also not rely on an implicit commit ...
but i am trying to analyse how the code exactly gets away without an
explicit commit
i will be adding an explicit commit statement in the code ..
( thats for sure ) !!!!!!! |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Apr 10, 2008 2:47 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| strom wrote: |
but i am trying to analyse how the code exactly gets away without an
explicit commit
|
I agree that this is a highly plausible theory. I would emphasise (which I don't think has come across too clearly) that if the factors (as detailed in the APG) for an implicit commit are met by a given application running in a given set of circumstances on a given platform then they will always be met for that application on those circumstances.
So if it works because if it gets an implicit commit once, it will work until something changes. It's this "something" which makes it a bad thing to rely on! Hence if you can determine that your application is doing an implicit commit, it's safe to infer it's always been doing an implicit commit.
Hope that clarifies the point I was ineptly driving at.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
|
|
