| Author |
Message
|
| reg.2008 |
 Posted: Thu Feb 10, 2011 8:34 am Post subject: Reading and Removing Messages based on messages processed |
 |
|
Newbie
Joined: 09 Feb 2011
Posts: 7
|
Hi
I'm trying to implement rescue mechanism to save each and every messages in DB in case of any processing failure.
To do that, i can't access message directly. I need to first read the message, try to save it in DB and then remove it from queue so that separate process will pick it up from DB to process it further (instead of separate queue we are using DB, project need  ). If saving in DB fails, don't remove message from the queue and wait till DB is up.
I have just started working with MQ's. Consider me as fresher in MQ's. I did search on this forum and google. Everybody suggested how to browse and how to move next. But no body ask for how to mark or remember which are already browsed (ver 6.x)? How to remove messages from the queue which are already browsed?
We are using Version 6.X
Any suggestions?? please welcome... |
|
| Back to top |
|
 |
| Vitor |
| Posted: Thu Feb 10, 2011 8:40 am Post subject: Re: Reading and Removing Messages based on messages processe |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| MQSeries.net wrote: |
| How to remove messages from the queue which are already browsed? |
Nice handle. 
Don't use browsing at all, for reasons you should have seen discussed here.
Destructively read the message in a unit of work so the message is rolled back onto the queue in the event of a database problem.
Also consider using this method for the actual processing of the messages and abandon the database completely. There's no need for it or a separate queue that I can see if all you're doing is preserving messages in the event of a problem. WMQ will do that on the original queue for you; it's one of the things you're paying the license fee for.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| reg.2008 |
| Posted: Thu Feb 10, 2011 8:51 am Post subject: Reading and Removing Messages based on messages processed |
|
|
Newbie
Joined: 09 Feb 2011
Posts: 7
|
| How though? Any reference to code? Reference to the topics already discussed? Any where else on internet ? |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Feb 10, 2011 9:03 am Post subject: Re: Reading and Removing Messages based on messages processe |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| MQSeries.net wrote: |
| Any reference to code? |
Sample code in all the usual places, including the installation media for WMQ
| MQSeries.net wrote: |
| Reference to the topics already discussed? |
Any topic talking about unit of work (UoW), syncpoint, rolling messages back or browsing is evil.
| MQSeries.net wrote: |
| Any where else on internet ? |
Pretty much the same terms as above. It's conceptually identical to UoW on a database.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Thu Feb 10, 2011 9:10 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| So the keywords here are "Syncpoint" and "Two-Phase commit". |
|
| Back to top |
|
|
| reg.2008 |
| Posted: Thu Feb 10, 2011 9:14 am Post subject: |
|
|
Newbie
Joined: 09 Feb 2011
Posts: 7
|
| and just to make sure, its possible in Version 6.x ?? |
|
| Back to top |
|
|
| mqjeff |
| Posted: Thu Feb 10, 2011 9:16 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| MQSeries.net wrote: |
| and just to make sure, its possible in Version 6.x ?? |
MQ has supported syncpoint and two-phase commit since version 5.0 at least.
But v6.0 goes out of support in April. So you don't want to do new development on it. |
|
| Back to top |
|
|
| reg.2008 |
| Posted: Thu Feb 10, 2011 9:28 am Post subject: |
|
|
Newbie
Joined: 09 Feb 2011
Posts: 7
|
Ok. Thanks for the help. So to conclude this thread, there is no way to mark message as read and later remove it based on db success/failure in Ver. 6.X ?
I'm try to get it without using "Syncpoint" and "Two-Phase commit". |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Feb 10, 2011 9:34 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| MQSeries.net wrote: |
| So to conclude this thread, there is no way to mark message as read and later remove it based on db success/failure in Ver. 6.X ? |
Or in v7, which you should be planning to move to given v6.n's out of support date. WMQ uses syncpointing to co-ordinate with external resources.
| MQSeries.net wrote: |
| I'm try to get it without using "Syncpoint" and "Two-Phase commit". |
Try looking at it this way. If you wanted to achieve the same thing with a database, i.e. select a row from a table and mark it as read so that no other select would pick it up and a later job could delete it, how would you achieve that? Same issues.
Syncpoint is not tricky.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Thu Feb 10, 2011 9:46 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
If you want exclusive access to the queue, then open it for exclusive input access.
If you want to ensure that the message is EITHER committed to the database or kept on the queue, USE TWO-PHASE COMMIT. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Thu Feb 10, 2011 12:37 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
|
| Back to top |
|
|
| mqjeff |
| Posted: Thu Feb 10, 2011 12:54 pm Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| PeterPotkay wrote: |
| mqjeff wrote: |
| But v6.0 goes out of support in April. |
Thanks for the panic attack!  |
Clearly I meant Broker v6.0.
 |
|
| Back to top |
|
|
| reg.2008 |
| Posted: Thu Feb 10, 2011 1:31 pm Post subject: |
|
|
Newbie
Joined: 09 Feb 2011
Posts: 7
|
I feel my question got diverted due to DB stuff i mentioned.
Let me put my question in different way, I need to read a message, process it without saving anywhere. If succeeds, remove from queue otherwise keep it on queue.
Is there any way to mark messages as already read?
Is there way to skip already read message and work with newly entered messages?
Remove based on some id?
Apologize if you are feeling i'm repeating my question  |
|
| Back to top |
|
|
| fatherjack |
| Posted: Thu Feb 10, 2011 1:47 pm Post subject: |
|
|
Knight
Joined: 14 Apr 2010
Posts: 522
Location: Craggy Island
|
| Quote: |
| MQ has supported syncpoint and two-phase commit since version 5.0 at least. |
V2 did I think. V1 (ezBridgeTransact) didn't even do assured delivery so I guess didn't do 2-phase commit too well. Unless anyone one from Apertus/SSI can tell me otherwise.
_________________
Never let the facts get in the way of a good theory. |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Feb 10, 2011 1:58 pm Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| MQSeries.net wrote: |
| Let me put my question in different way, I need to read a message, process it without saving anywhere. If succeeds, remove from queue otherwise keep it on queue. |
I think we got that.
| MQSeries.net wrote: |
| Is there any way to mark messages as already read? |
Only by reading them off the queue.
| MQSeries.net wrote: |
| Is there way to skip already read message and work with newly entered messages? |
No.
| MQSeries.net wrote: |
| Remove based on some id? |
You can read a specific message off by quoting it's id or by reading the message that's under the browse cursor. This only works for 1 message at a time; if you browse a second message the first becomes available for reading again.
You could keep a list of all the message id's you've processed, check that list each time you browse a message to see if you've already processed it, update the list everytime you successfully update the database and then remove the message the next time you browse the queue.
But you're going to tie yourself in knots keeping that straight and the code is going to be considerably more complex than establishing a unit of work.
Also be aware that browsing a queue is considerably less efficient than reading it, like using a browse cursor on a database is less efficient than a select. If performance is or ever will be an issue don't browse.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
|
|
