| Author |
Message
|
| kiranshet89 |
 Posted: Fri Mar 13, 2015 8:03 am Post subject: publication node/mqoutput node transactionality |
 |
|
Newbie
Joined: 13 Mar 2015
Posts: 8
|
Hi Experts,
I have a requirement where I need to publish messages to multiple subscribers using IIB.Just it case it fails to publish messages to all subscribers then it has to roll back.For example:if i have 4 subscribers the message should either be published to all the 4 subscribers and,if it fails to publish to any one of the subscriber then no subscriber should recieve the message and the message has to be rolled back.Please let me know how to implement this scenario. |
|
| Back to top |
|
 |
| Vitor |
| Posted: Fri Mar 13, 2015 8:23 am Post subject: Re: publication node/mqoutput node transactionality |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| kiranshet89 wrote: |
| Please let me know how to implement this scenario. |
You shouldn't.
The essence of publish / subscribe is that the publisher and the subscribers are decoupled. If you have the kind of dependancy you're describing, then the 4 "subscribers" should be sent separate and distinct messages.
| kiranshet89 wrote: |
| it fails to publish messages to all subscribers |
What do you mean by "fail to publish"?
- IIB abends trying to serialize the message for publication
- IIB publishes the message but one message gets stuck on the IIB queue manager's proxy subscription
- IIB publishes all the messages which reach their destination but one of the subscribers is not registered at the time
- IIB publishes all the messages which reach their destination but one of the subscribers is deadlocked with a database at time of receipt
All of these scenarios require a different kind of "failure" detection.
Also, if you have 4 subscribers now, what is the likelyhood of there being 5 subscribers in future? Or 3?
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Fri Mar 13, 2015 8:25 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| How are you going to distinguish between "fail to publish" and "fail to receive" or "subscribe discards message"? |
|
| Back to top |
|
|
| ganesh |
| Posted: Fri Mar 13, 2015 9:11 am Post subject: |
|
|
Master
Joined: 18 Jul 2010
Posts: 294
|
|
| Back to top |
|
|
| kiranshet89 |
| Posted: Fri Mar 13, 2015 11:22 am Post subject: |
|
|
Newbie
Joined: 13 Mar 2015
Posts: 8
|
Thanks for the comments.
My requirement is I need send,the output messages to 4 different queues which would be picked up by 4different applications.If iib is unable to put the message to say atleast one of the queue(say the 3rd queue due to network issue or any other issue) then the message that is being put into the first two queues should be rolled back, in other words the first two applications that listen to queue 1 and 2,must not be able to process it.If this is not possible using publish/subscribe,then what other ways do u guys suggest me to implement this.Inshort I want the messages to be be put into 4 different queues under one transaction. |
|
| Back to top |
|
|
| McueMart |
| Posted: Fri Mar 13, 2015 11:29 am Post subject: |
|
|
Chevalier
Joined: 29 Nov 2011
Posts: 490
Location: UK...somewhere
|
Im going to answer a bit of a different question, just in case this is what you are really asking (although I completely agree with the sentiments of the 3 answers before me).
The Publication node in WMB/IIB is non-transaction, and there is currently no way to put within the broker transaction. If you want your 'publications' to be transaction (If for example you are publishing multiple messages within a broker transaction), you can replace your Publication node with an MQOutput node (set to Transaction=Yes), and then have a separate flow which reads off this 'to be published' queue, and published the messages out.
I vaguely recall there was a RFE to have Transactionality added to the publication node, or maybe I was dreaming. |
|
| Back to top |
|
|
| McueMart |
| Posted: Fri Mar 13, 2015 11:35 am Post subject: |
|
|
Chevalier
Joined: 29 Nov 2011
Posts: 490
Location: UK...somewhere
|
So these 4 applications which are picking up the subscriptions are distributed? And you want to 100% guarantee that ONLY IF all 4 of them successfully receive the message, they will all process it, OTHERWISE none of them should process the message.
This is a non trivial problem - akin to creating your own distributed 2-phase commit protocol.
MQ assures delivery which means that if the destination exists, and a route to it exists, MQ will get the message there. But it does not guarantee it will get the message to a destination (If for example there is a network problem!)
Last edited by McueMart on Fri Mar 13, 2015 11:36 am; edited 1 time in total |
|
| Back to top |
|
|
| Vitor |
| Posted: Fri Mar 13, 2015 11:35 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| kiranshet89 wrote: |
| If this is not possible using publish/subscribe,then what other ways do u guys suggest me to implement this.Inshort I want the messages to be be put into 4 different queues under one transaction. |
Then put 4 messages as part of the same transaction using the MQOutput node.
But:
| kiranshet89 wrote: |
| If iib is unable to put the message to say atleast one of the queue(say the 3rd queue due to network issue or any other issue) |
If you put a message in IIB and the network link to one of the target queues is down then the put will succeed and the message will sit in the transmission queue until the network problem is resolved. This is one of the features of WMQ - that messages are assured to arrive and the sending application doesn't need to worry about it. If your requirement is that you want to worry about all 4 messages arriving then you need to use something other than WMQ.
And you still don't say what you're going to do if WMQ delivers the message to the target queue but the consuming application isn't running
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Fri Mar 13, 2015 11:39 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| Or what you're going to do if the target application deletes the message or otherwise simply fails to process it. |
|
| Back to top |
|
|
| Vitor |
| Posted: Fri Mar 13, 2015 11:41 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| McueMart wrote: |
| This is a non trivial problem - akin to creating your own distributed 2-phase commit protocol. |
What you need to build is a mechanism that not only sends the messages but uses the COA & COD messages to confirm the messages have been processed, sending "rollback" messages to the 1-3 applications that did process the messages if the 4th doesn't respond inside a timeout period.
This is a world of hurt.
Consider these scenarios:
- The COD message for one application doesn't arrive so you message the other 3 to rollback. 4 seconds late the network issue you're worried about is fixed and the 4th COD turns up. Do you rollback that application, or tell the other 3 to rollback their rollback?
- The COD message for one application doesn't arrive so you message the other 3 to rollback. Due to the kind of network issue you're worried about the rollback message is never delivered to one of these application that did receive the original message. Now 1 application has it processed and the other 3 don't.
This has been discussed a lot on this forum. You're making a rod for your own back. A large, metal, steam powered rod with spikes on it.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Fri Mar 13, 2015 1:41 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Not quite. I know it is possible to set up the pub sub so that all get it or none get it. Don't know what the response would be to the publisher, but if you add an administrative subscription for the broker you can check if you got the publication and if not throw a rollback. Or add a lowest level receive interceptor and if you got something it means that nobody got it...
Anyways the pattern is not good there. Think about it and see if you can re engineer it ...
The only reason you'd do something like this is if one of the queues gets full and dlq is full? Monitoring should take care of the problem automatically.
And with 8.0 and JMS message delay, how would handle that scenario? Re-engineer!
_________________
MQ & Broker admin |
|
| Back to top |
|
|
|
|
