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.
