| Author |
Message
|
| mqjeff |
 Posted: Fri May 18, 2012 7:41 am Post subject: |
 |
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| lodha13 wrote: |
| If we dont use syncpoint I will not be able to backout in the queue. I am using syncpoint. |
Your backout procedure is producing results that are inconsistent with using an MQ syncpoint to rollback a transaction.
So either your backout procedure is NOT rolling back the MQ syncpoint, or your reporting of the messages on the queue is wrong, or you've done something horrendous.
Nobody here has advocated that you DO NOT use syncpoint. We are attempting to convince you that you need to create new objects in your code. That does not change the syncpoint. |
|
| Back to top |
|
 |
| lodha13 |
| Posted: Fri May 18, 2012 7:44 am Post subject: |
|
|
Novice
Joined: 17 May 2012
Posts: 24
|
| That makes sense creating new message object but GMO |
|
| Back to top |
|
|
| mqjeff |
| Posted: Fri May 18, 2012 7:47 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| lodha13 wrote: |
| That makes sense creating new message object but GMO |
Again, if you have one GMO object that has the same properties as another, then it does not matter that they are two objects.
And, again, you need to pay attention to whether or not the gmo object is an in/out parameter or only an in parameter to the GET.
If it's only an In parameter, you don't need a new one.
In general when dealing with Groups, people do update the GMO for each GET, because they specify to get the FIRST message in the group and then they specify to get the NEXT message in the group after that. |
|
| Back to top |
|
|
| lodha13 |
| Posted: Fri May 18, 2012 8:05 am Post subject: |
|
|
Novice
Joined: 17 May 2012
Posts: 24
|
One more question.
initialize GMO object
GMO = syncpoint + others
read one good message
again define gmo = syncpoint
read one more good message
backout()
I have tried this scenario but it is backing out even the first read message. I thought it will backout till the syncpoint.
I am using same GMO object. Is it a problem.
I mean can I change the sync point after each message read |
|
| Back to top |
|
|
| Vitor |
| Posted: Fri May 18, 2012 8:33 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| lodha13 wrote: |
| I have tried this scenario but it is backing out even the first read message. I thought it will backout till the syncpoint. |
That's because you're still not understanding what syncpoint means, does or how in works in addition to how you need to code it.Adding the option to the GMO is one part of the process (I've used bold as you don't seem to understand underline either).
| lodha13 wrote: |
| I am using same GMO object. Is it a problem. |
I repeat my advice to read all of the answers you're being given, not just skim the bits you think are relevant.
| lodha13 wrote: |
| I mean can I change the sync point after each message read |
Yes. First you need to decide how many of the input messages form a transactional group, then you need to establish that transactional group.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Fri May 18, 2012 9:03 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
A transaction comprises all gets/puts in SYNCPOINT, and BEFORE a commit or backout.
Messages get (past tense) in SYNCPOINT exist in the queue unchanged; BUT are marked as invisible - meaning that no other application can consume them.
So, you must get all of the messages that are part of your transaction; and then backout if you find one or more messages don't meet your business requirement.
Once committed, messages are destroyed from the queue. Alternatively, once backed out, messages are available for other apps to consume.
_________________
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 |
|
|
| lodha13 |
| Posted: Fri May 18, 2012 10:46 am Post subject: |
|
|
Novice
Joined: 17 May 2012
Posts: 24
|
Here are my requirements
I cannot change the GMO Object for each message in gourp
I am using different MQMessage so that properties does not pass to the next message.
I want to change the syncpoint(by syncpoint i mean that till this point it will backout. Please correct if I am wrong instead os simply telling that I am wrong) as soon as the message is read.
Is there any way or I have to necessarily create new GMO's. I mean in the same GMO can we again put syncpoint after some messages are read
Thanks for all these help |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Fri May 18, 2012 10:57 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Explain first why you would want to change your GMO within a single unit of work 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| lodha13 |
| Posted: Fri May 18, 2012 11:14 am Post subject: |
|
|
Novice
Joined: 17 May 2012
Posts: 24
|
| fjb_saper wrote: |
| Explain first why you would want to change your GMO within a single unit of work |
I said I do not want change GMO.
There is a group of message. A group can contain any number of message. In current test case there are 4 messages 2 good +1 bad+1 good
Now my application reads 2 good msg and then as soon as it reads 3 msg it throws error(expected) I call backout. When I call this backout even the previously read 2 msg are backed out (expected as syncpoint is defined at that point, which I dont want). I want that as soon a message is read successfully dont back it out.
1) This is my requirement. Now is it possible without changing the GMO(i cannot change GMO)
2) One thing I tried, which I already told did not work
intitalize
gmo = syncpoint+others
read msg //dont want it backout when backout() is called
gmo+=syncpoint //on the same gmo please tell if this is not correct
read second message
gmo+syncpoint
read third msg
error 2111 call backout() |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Fri May 18, 2012 12:22 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
Please read this, then re-read this:
A Unit of Work occurs between consistent states.
A Unit of Work begins when you put/get a message in _SYNCPOINT, and ends when you MQCMIT or MQBACK (or the Java/JMS equivalents.
For each message, the application decides (with MQGMO structure) if this get is to be in SYNCPOINT or outside SYNCPOINT. In SYNCPOINT (MQGMO with _SYNCPOINT) tells the mq to give the app a copy of the message, but not destructively. MQGMO with _NO_SYNCPOINT) tells mq to destructively get the message. (MQPUT, with MQPMO works the same.)
All message(s) get in SYNCPOINT will be part of a single Unit of Work. MQCMIT and MQBACK commit or backout all of the messages consumed with MQGMO_SYNCOINT.
WMQ offers no method of doing what you are asking for, namely: the ability to commit some, but not all of the messages gotten in SYNCPOINT in the UofW.
[edit]
And, WMQ only allows for one UofW at a time within an application. Commit/backout are based on the connection handle (HCONN) received from the successful MQCONNect.
[/edit]
_________________
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 |
|
|
| fjb_saper |
| Posted: Fri May 18, 2012 8:31 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
what you want to do is following:
set a rollback flag to false
read all messages in the group one by one.
If you need to rollback you set the rollback flag to true.
You still need to read the remaining messages in the group.
At the end of the group check the rollback flag and decide accordingly.
This way all messages in the group will have the same retry count...
Have fun
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Sat May 19, 2012 6:55 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
Unless I've misunderstood the OP, lodha13 wants to backout only some of the messages - not all messages - consumed in -SYNCPOINT. While this is supported in z/OS (with MARK_SKIP_BACKOUT), it is not supported on other platforms.
lodha13 could code an app to get all of the messages in the group destructively, and store the message in the app (or DB), then commit all of them out of the queue.
Next, the app could determine which of the messages should/should not be "backed out" to the queue, then (not using MQBACK) put the messages needing backout to the queue in a new UofW. If the original messages are to maintain their original MQMD, the app must have sufficient authority to fiddle with message context and other MD fields.
This all seems a bit risky.
_________________
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 |
|
|
| rekarm01 |
| Posted: Sat May 19, 2012 12:23 pm Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 1415
|
| lodha13 wrote: |
| I said I do not want change GMO. |
In case it's still not clear, every call to MQQueue.get() can change the MQMessage MQMD and MQGMO arguments; this can cause unexpected behavior if the application re-uses these arguments in subsequent calls to MQQueue.get(). The application is responsible for ensuring that these arguments are set correctly before each get(), either by creating new MQMessage or MQGMO objects, or by re-initializing existing objects.
| lodha13 wrote: |
| I want that as soon a message is read successfully dont back it out. |
Then call MQQueueManager.commit() instead, so the message can't get backed out later. It's a bit unusual to commit/backout each message in a group individually, rather than commit/backout the group as a whole, but it's easy enough to implement; place the commit/backout calls inside the get loop, rather than afterwards. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Sat May 19, 2012 1:00 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| lodha13 wrote: |
Yes its a group with the same group id.
All the good message arrive with the same CCSID(437) and bad message with different(451)
I am putting the message with some tool. |
It is the producing (putting) application that sets the CCSID (and most other fields) in the MQMD. While unusual, it is possible that the producing application created some of the messages in the group with a different CCSID.
Ask the application programmer to explain why this was done.
[edit]
CCSID 451?
Did you search the Application Programming Reference? Did you search google? A quick spin through the WMQ APR, followed by a google search for CCSID 451, leads me to believe, like the manual says:
2115 (0843) (RC2115): MQRC_TARGET_CCSID_ERROR
Explanation
The coded character-set identifier to which character data is to be converted is not valid or not supported.
[/edit]
_________________
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 |
|
|
|
|
