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
