I tried with the xa tm and it works fine for now. To manage a fault on the JBI exchange would you use a robust MEP? I insist on this point as I can't afford to loose any message! You said "the JMS message will be redelivered later" but in fact it's immediately, I mean with no delay, isn't it? Is it a way to set a redelivery interval to avoid the WS to be called 10 times per second with the same message whereas the service is not available for a while?
gnodet wrote: > > In your case, XA is fine because there will be no two-phase commits > and no tx logs. > We're using the transaction manager from jenks (which delegates to the > geronimo tx mgr). > You can find the code at: > > https://svn.apache.org/repos/asf/geronimo/components/txmanager/trunk/geronimo-transaction/ > > For the redelivery stuff, if the JBI exchange is in an ERROR state > (for example because the web service was not available and the > connection failed), the transaction will be rolled back and the JMS > message will be redelivered later. A fault on the JBI exchange won't > cause a rollback because faults are considered in a different way. > > On Thu, Oct 23, 2008 at 4:27 PM, pwanner <[EMAIL PROTECTED]> wrote: >> >> The point about not using an XA transaction was to avoid the slow >> two-phase >> commit, as the throughput is a real concern. >> But also to avoid to have an other transaction manager with tx logs to >> configure and monitor. By the way, witch transaction manager are you >> talking >> about in the scenario you described? The jenks one? >> Anything about the recovery delay if the WS is down or generate a fault >> and >> the message is rolledback? >> >> Regards >> Philippe Wanner >> >> >> gnodet wrote: >>> >>> Why not using XA transactions ? The transaction manager is optimized >>> so that if there is only a single transacted resource (which would be >>> the case, as only the JMS connection factory would be used), it will >>> bypass the two-phase commit and simply commit the underlying JMS >>> transaction. In such a case, nothing is written to disk or whatever, >>> so there is no overhead. >>> This use case using XA works fine in servicemix. It may be possible >>> to do the same with JMS transactions only, but this is not really >>> supported. >>> >>> On Thu, Oct 23, 2008 at 3:29 PM, pwanner <[EMAIL PROTECTED]> wrote: >>>> >>>> Hi everyone, >>>> >>>> I have an oportunity to introduce ServiceMix in my company, through >>>> this >>>> simple use case: >>>> >>>> 1. Read a message in a MQSeries queue >>>> 2. Call a websevice and pass it the message >>>> 3. Get back the message from the ws and post it in an other MQSeries >>>> queue >>>> >>>> But there are some constraints: >>>> - This has to be done under the same JMS transaction, so that if there >>>> is >>>> any problem calling the WS, the get from the first queue is rolled back >>>> and >>>> the message is not lost. >>>> - JMS transaction and NOT XA transaction. >>>> - If there is a problem calling the WS the retry has to be delayed (let >>>> say >>>> 30 sec) to ensure that we are not falling in a "mad" loop of retries. >>>> >>>> This is very easy with standard Java code I don't know if this is >>>> possible >>>> with ServiceMix. >>>> >>>> I know that the jms:consumer has a transacted="jms" attribute but it >>>> seems >>>> to me that it's a transaction spanning just the get from the queue and >>>> the >>>> send to the NMR. >>>> >>>> I have already done the binding of the jms:consumer and the >>>> jms:provider >>>> with the MQSeries queue, bridged the call to the http:provider through >>>> an >>>> eip:pipeline (jms:consumer -> eip:pipeline -> http:provider -> >>>> jms:provider), but for the JMS transaction and the delayed retry I >>>> didn't >>>> find anything. >>>> >>>> Does anyone has any advise? >>>> >>>> Thank you and best regards >>>> Philippe >>>> >>>> >>>> >>>> >>>> -- >>>> View this message in context: >>>> http://www.nabble.com/JMS-transaction-and-delayed-retry-tp20130976p20130976.html >>>> Sent from the ServiceMix - User mailing list archive at Nabble.com. >>>> >>>> >>> >>> >>> >>> -- >>> Cheers, >>> Guillaume Nodet >>> ------------------------ >>> Blog: http://gnodet.blogspot.com/ >>> ------------------------ >>> Open Source SOA >>> http://fusesource.com >>> >>> >> >> -- >> View this message in context: >> http://www.nabble.com/JMS-transaction-and-delayed-retry-tp20130976p20132153.html >> Sent from the ServiceMix - User mailing list archive at Nabble.com. >> >> > > > > -- > Cheers, > Guillaume Nodet > ------------------------ > Blog: http://gnodet.blogspot.com/ > ------------------------ > Open Source SOA > http://fusesource.com > > -- View this message in context: http://www.nabble.com/JMS-transaction-and-delayed-retry-tp20130976p20133175.html Sent from the ServiceMix - User mailing list archive at Nabble.com.
