| Author |
Message
|
| goffinf |
 Posted: Tue Mar 20, 2007 9:38 am Post subject: MQGet Transaction handling |
 |
|
Chevalier
Joined: 05 Nov 2005
Posts: 401
|
WBIMB v6
Hi,
I am putting together a flow which includes an MQGet (this message is used along with the message input to the flow). I haven't used this node before so I am unsure about how to handle exceptions that occur following a successful GET.
The flow does the MQGet fairly early on, and then does a whole bunch of other stuff. There is reasonable potential for something to exception in the flow, and if it does, I want the message that I got via MQGet to roll back onto its queue.
I have read through the MB help and it talks about the Transaction Mode property which seems to be in the area of what I need. I have also read various posts on this forum, some of which talk about MQGET with SYNCPOINT. Unfortunately none of these sources as yet has really explained what the critical details are at least in simple enough terms for me (still relatively novice).
Can anyone provide a simple pattern to follow to acheive what I need, and identify the critical config settings and/or eSQL required.
Much appreciated
Fraser. |
|
| Back to top |
|
 |
| marcin.kasinski |
| Posted: Tue Mar 20, 2007 12:44 pm Post subject: Re: MQGet Transaction handling |
|
|
Sentinel
Joined: 21 Dec 2004
Posts: 850
Location: Poland / Warsaw
|
Hi goffinf,
For me it's quite wide topic.
As you mentioned there is transaction mode property.
Description of this property you can find in docs.
It's very hard to answer your question.
It depends on many things how can you implement it.
Sometimes you have to rollback message (Transaction mode= yes and persistent =true ), sometimes you have to commit transaction and do some error processing (try catch nodes)
_________________
Marcin |
|
| Back to top |
|
|
| jsware |
| Posted: Wed Mar 21, 2007 1:59 am Post subject: Re: MQGet Transaction handling |
|
|
Chevalier
Joined: 17 May 2001
Posts: 455
|
| goffinf wrote: |
| I have read through the MB help and it talks about the Transaction Mode property which seems to be in the area of what I need. I have also read various posts on this forum, some of which talk about MQGET with SYNCPOINT. Unfortunately none of these sources as yet has really explained what the critical details are at least in simple enough terms for me (still relatively novice). |
If you set the transaction mode to automatic, then it will take on the transaction mode of your MQInput node. If you set transaction mode=yes, you will for the MQGet node to start a transaction even if the MQInput node did not. If you set it to No, MQGet will not use a transaction, even if one was started by the MQInput node.
Now onto the MQInput node. If you set to automatic, then a transaction is started if the message is persistent, none is started if the message is non-persistent. If you set to yes (the default), then MQInput always starts a transaction. Set to no and (you guessed it) MQInput never starts a transaction.
If a transaction is started, those messages got/put within that transaction will get rolled back if an exception occurs.
Be careful when wiring up the catch terminal of your input node. If you do, then the transaction is not rolled back, you catch nodes get a chance to do something. If they complete successfully, your whole transaction gets committed.
Thus you probably want to have MQInput transaction mode = yes/auto and MQGet transaction mode = auto.
_________________
Regards
John
The pain of low quaility far outlasts the joy of low price. |
|
| Back to top |
|
|
| goffinf |
| Posted: Sat Mar 31, 2007 9:39 am Post subject: Re: MQGet Transaction handling |
|
|
Chevalier
Joined: 05 Nov 2005
Posts: 401
|
Thanks John.
If I set the MQGet node to start a new transaction at what point is that comitted. That is, if I read from the queue, then do some more work on that message which results in an exception, does the original get rolled back onto the queue ?
Fraser. |
|
| Back to top |
|
|
| jsware |
| Posted: Mon Apr 02, 2007 6:25 am Post subject: Re: MQGet Transaction handling |
|
|
Chevalier
Joined: 17 May 2001
Posts: 455
|
| goffinf wrote: |
| If I set the MQGet node to start a new transaction at what point is that comitted. That is, if I read from the queue, then do some more work on that message which results in an exception, does the original get rolled back onto the queue ? |
My belief would be that when you exception is not caught by a wired up catch terminal that it would get rolled back at that point.
However, if you never have MQInput begin a transaction, I would hope that it realises a transaction has been started and roll it back. I would recommend thorough testing of your exception scenario however - you might want to write a little proof-of-concept flow to test what happens:
MQInput{txn=No} -> MQGet{txn=Yes} -> Throw
_________________
Regards
John
The pain of low quaility far outlasts the joy of low price. |
|
| Back to top |
|
|
| goffinf |
| Posted: Wed Apr 04, 2007 1:16 am Post subject: Re: MQGet Transaction handling |
|
|
Chevalier
Joined: 05 Nov 2005
Posts: 401
|
However, if you never have MQInput begin a transaction, I would hope that it realises a transaction has been started and roll it back. I would recommend thorough testing of your exception scenario however - you might want to write a little proof-of-concept flow to test what happens:
MQInput{txn=No} -> MQGet{txn=Yes} -> Throw[/quote]
Thanks John, I will do some testing around this and post back my observations. My particular flows do not start with MQInput so there is no transaction mode setting in operation (AFAIK ?) until the MQGet is reached. I guess I am just trying to determined that once I've moved off the MQGet node itself and I am in subsequent nodes in the flow, whether the message has been destructively removed form the queue or whether this waits until the whole flow terminates without exception.
P.S Sorry for the double POST, I wanted to ask the question about MQGet separately from the broader topic of transactionality.
Fraser. |
|
| Back to top |
|
|
| jsware |
| Posted: Wed Apr 04, 2007 8:41 am Post subject: Re: MQGet Transaction handling |
|
|
Chevalier
Joined: 17 May 2001
Posts: 455
|
| goffinf wrote: |
| My particular flows do not start with MQInput so there is no transaction mode setting in operation (AFAIK ?) |
What are they starting with? I am assuming some other kind of input node (HTTPInput, JMSInput or some such). Some of these might have a transaction mode setting.
_________________
Regards
John
The pain of low quaility far outlasts the joy of low price. |
|
| Back to top |
|
|
| goffinf |
| Posted: Thu Apr 05, 2007 9:54 am Post subject: Re: MQGet Transaction handling |
|
|
Chevalier
Joined: 05 Nov 2005
Posts: 401
|
| scottj2512 wrote: |
| goffinf wrote: |
| My particular flows do not start with MQInput so there is no transaction mode setting in operation (AFAIK ?) |
What are they starting with? I am assuming some other kind of input node (HTTPInput, JMSInput or some such). Some of these might have a transaction mode setting. |
A custom ipnut node that is a wrapper to our web service stack implementation (based on AXIS2). It doesn't have any transaction mode setting although it does implement it own transaction manager JOTM. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Thu Apr 05, 2007 10:05 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
| goffinf wrote: |
| A custom ipnut node that is a wrapper to our web service stack implementation (based on AXIS2) |
Ouch. You've just given me a headache.
I would have advised you to run AXIS2 in a separate container, like Tomcat, and used it to invoke web services built using HTTPInput nodes and possibly use IE01 to provide better scalability.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| goffinf |
| Posted: Fri Apr 06, 2007 9:30 am Post subject: |
|
|
Chevalier
Joined: 05 Nov 2005
Posts: 401
|
| jefflowrey wrote: |
| goffinf wrote: |
| A custom ipnut node that is a wrapper to our web service stack implementation (based on AXIS2) |
Ouch. You've just given me a headache.
I would have advised you to run AXIS2 in a separate container, like Tomcat, and used it to invoke web services built using HTTPInput nodes and possibly use IE01 to provide better scalability. |
It does run in its own container, Message Broker is just the endpoint of a IPC bridge. As you might expect we have a Input, Reply and Request node. This provides complete abstrction for the MB developer from anything to do with web services, and yet the web service functionality is everything that is on offer from AXIS, plus some additions of our our for common service endpoint capabilities such as logging, monitoring, security, validation, transformation, etc, etc. So a MB flow can be exposed as a composite service and in turn it can call an be called from any service endpoint on our ESB over any combination of transport and messaging protocol that is supported (HTTP, JMS, SMTP, RMI, SOAP, etc...)
Finally we are starting to see the seeds of some native support for this sort of thing inside MB itself (in 6.1), but in some ways I am happy with the abstraction and separation of the concerns as we have them now.
Fraser. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Fri Apr 06, 2007 4:02 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
The MQ Input, Request, Reply nodes provide a complete abstraction for the MB developer from anything to do with webservices.
And MQ is significantly more reliable, trackable, manageable, and etc. than RMI/IPC.
The MQ wheel is very very round. How round is your re-invention?
But this is just my opinion.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| goffinf |
| Posted: Sat Apr 07, 2007 4:51 am Post subject: |
|
|
Chevalier
Joined: 05 Nov 2005
Posts: 401
|
| jefflowrey wrote: |
The MQ Input, Request, Reply nodes provide a complete abstraction for the MB developer from anything to do with webservices.
And MQ is significantly more reliable, trackable, manageable, and etc. than RMI/IPC.
The MQ wheel is very very round. How round is your re-invention?
But this is just my opinion. |
Indeed they do and of course you are absolutely correct to question any re-invention of mature technology.
I would comment though that web service support is not something that Message Broker with or without MQ provides in any great depth at present. So really all I'm saying is we are attempting to use the right tool for the job. AXIS is a mature, stable and relatively feature rich web services implementation, that I also don't want to re-invent inside MB. MB provides a mature technology for what it does best, hence the marriage of the two. I don't believe there is a great deal of overlap here (at least not yet - v6.1 provides a littel more).
Fraser. |
|
| Back to top |
|
|
| SixBlade |
| Posted: Thu Sep 20, 2007 6:15 am Post subject: |
|
|
Apprentice
Joined: 03 Dec 2003
Posts: 26
Location: UK
|
Hi,
some testing regarding this:
queue "A", with message #1
queue "B", with message #2
Flow with MQInput(q A) --> MQGet(q B) --> Throw
If
-MQInput:trans = yes
-MQGet:trans = yes
--> message #1 rolled back, message #2 rolled back
If
-MQInput:trans = no
-MQGet:trans = yes
--> message #2 rolled back
If
-MQInput:trans = yes
-MQGet:trans = no
--> message #1 rolled back
In all cases, the flow must get the exception, as it will in the config above. If MQInput -> trycatch -> MQGet -> throw, nothing gets rolled back, unless the catch path on the trycatch does another throw.
This should mean, amongst other facts, that an MQGet, as long as it has trans=yes(forced), and the flow exceptions, it will rollback. I have tested this with a custom inputnode instead of the MQInput node, there it's always trans=no for the input node, and the MQGet follows the same rule as above. |
|
| Back to top |
|
|
|
|
