| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Problems with errored messages read under a syncpoint |
« View previous topic :: View next topic » |
| Author |
Message
|
| squig |
 Posted: Mon Aug 06, 2007 10:42 pm Post subject: Problems with errored messages read under a syncpoint |
 |
|
Newbie
Joined: 06 Aug 2007
Posts: 3
|
Hi there, I'm currently having a problem (both conceptually and pragmatically) about how transactions work with backout counts using the .net MQ interface.
Here is my problem:
I'm currently making some updates to an internal .net framework component that wraps all MQ related stuff for our consuming applications.
Exposed to these applications are the MQ Single-phase commit transactions So Begin, Commit & Backout.
So if the consuming application calling my component starts a transaction, then as part of this transaction i find that the back out count exceeds the back out threshold. I need to write the message out to a error queue, which i do outside of the transaction.
All is fine it the consuming application then commits the transaction, but it it backs out the transaction the 'poison' message is now back on the input queue.
I was told that i needed to use the mark_skip_backout flag by our EAI people, but this option is only available under z/OS. Is there an equivalent work around for doing this using the .net interface?
I've tried doing a get by message id after the abort, but as I'm dealing with a multi threaded program, another copy could have already read in the offending message.
I have found to following in the MQ Doco about transactions but haven't seen any details about how to remove a message from a syncpoint as this snippet eludes to being able to do.
| Quote: |
| To help handle units of work, WebSphere MQ provides the BackoutCount attribute. This is incremented each time that a message within a unit of work is backed out. If the message repeatedly causes the unit of work to abend, the value of the BackoutCount finally exceeds that of the BackoutThreshold. This value is set when the queue is defined. In this situation, the application can remove the message from the unit of work and put it onto another queue, as defined in BackoutRequeueQName. When the message is moved, the unit of work can commit. |
this is from http://publib.boulder.ibm.com/infocenter/wmqv6/v6r0/index.jsp?topic=/com.ibm.mq.csqzal.doc/fg13620_.htm
Any pointers appreciated.
Last edited by squig on Tue Aug 07, 2007 5:51 pm; edited 1 time in total |
|
| Back to top |
|
 |
| fjb_saper |
| Posted: Tue Aug 07, 2007 2:52 am Post subject: Re: Problems with errored messages read under a syncpoint |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| squig wrote: |
So if the consuming application calling my component starts a transaction, then as part of this transaction i find that the back out count exceeds the back out threshold. I need to write the message out to a error queue, which i do outside of the transaction.
Any pointers appreciated. |
Why do you perform the backout process outside of the UOW? It needs to be part of the UOW! The logic should be:
start transaction
read message
check backout count
If > threshold {
move to backout queue
commit
} else {
do your normal message processing
commit or rollback
}
end transaction
Enjoy
End transaction 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| squig |
| Posted: Tue Aug 07, 2007 5:48 pm Post subject: |
|
|
Newbie
Joined: 06 Aug 2007
Posts: 3
|
Normaly that would be the way i would do it, but in this situation i don't have control of the transaction, the consuming application does.
So it looks like this
Consuming appliaction starts transaction
Consuming application asks for a message to be read
My code reads the message
check backout count
If > threshold {
move to backout queue
pass message to consuming application
message processed by consuming application
consuming application calls comit or rollback
If i move the message to the error queue in this unit of work the consuming application can call rollback and my error message will be removed from the error queue, and the message that has exceded the BOT will be back on the input queue.
It is this putting the message back on the input queue if the BOC >= the BOT that i'm trying to get around. It's made a bit difficalt by the fact that my application isn't in controll of the transaction.
So I'm trying to find a way to remove the message from the syncpoint so that if the consuming application does call backout the messages in that syncpoint that have errored wont be put back on the input queue. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Tue Aug 07, 2007 8:13 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| Quote: |
If > threshold {
move to backout queue
pass message to consuming application
message processed by consuming application
consuming application calls comit or rollback |
Well here is your problem.
If > threshold
move to backout queue
do not pass message to consuming application but go to next step in your code if need be call commit yourself!
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| squig |
| Posted: Tue Aug 07, 2007 8:44 pm Post subject: |
|
|
Newbie
Joined: 06 Aug 2007
Posts: 3
|
That is the path i have followed for consuming applications using MQ transactions, but There are consuming applications that use an external DTC to co-ordanate transactions.
In this case my application doesn't see the transaction as the DTC conects directly the MQQM, so can't commit it myself. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Wed Aug 08, 2007 1:47 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| squig wrote: |
That is the path i have followed for consuming applications using MQ transactions, but There are consuming applications that use an external DTC to co-ordanate transactions.
In this case my application doesn't see the transaction as the DTC conects directly the MQQM, so can't commit it myself. |
If you use an external TM to coordinate the transaction, usually the program has access to the TM and the current transaction, either through the Environment or session etc...
Anyways if you do not give the program any reason to throw an exception and just let the stacked calls complete, you will most probably get your session to commit the message.
Enjoy
_________________
MQ & Broker admin |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
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
|
|
|
|
