I would like the option of enabling roll backs for runtime exceptions in cxf 3 when I eventually upgrade. Does cxf 3 at least cater for a error in middle of process where by the reply is never delivered but the request has disappeared so essentially there is no evidence of wother message. At least with the transaction even if it's just the spring JMS transaction manager both messages will be delivered or neither will. On 05/12/2014 8:44 PM, "Christian Schneider" <[email protected]> wrote:
> Honestly I am not sure about the code in getRollbackRuntimeException (in > your code). Maybe Dan knows. He added the code. > I was never sure how well the transactions in cxf 2 really worked. > > I just checked the code in CXF 3. > There I decided to completely avoid rolling back transactions for > request/reply. I think the reason is that the caller expects a reply. > The issue is that if you roll back then the message broker will retry a > number of times and then move the message to a dead letter queue. > So in this case the caller would get no reply at all. > > This is why I decided that a request/reply will always return the > exception to the caller. I have not found any materials on the net if this > is the right choice. > So we should discuss this here. > > Christian > > > On 05.12.2014 07:33, Jason Pell wrote: > >> Hi Christian, >> >> I have added a test case to my github branch which demonstrates the >> session >> issue and fails as a result. The session in the session holder is the >> same as the session passed into the onMessage method. >> >> In the jms systests: >> >> org.apache.cxf.systest.jms.tx.JMSTransactionClientServerSameSessionTest >> >> Currently when it executes, a soap fault is returned immediately. What >> actually should be happening is a rollback of the message occurs, and the >> GreeterImplWithTransaction then flips the boolean flag >> and returns a valid result. >> >> I have debugged this test and it fails to perform the rollback because of >> this test: >> >> boolean trans = resourceHolder == null || >> !resourceHolder.containsSession(session); >> >> The resourceHolder does contain the session. Where as for all other test >> cases (and my own which use both websphere mq and activemq), the sessions >> do not match. >> >> I need to understand exactly why the resource holder having the session >> means trans = false.... >> >> Thanks >> >> > -- > Christian Schneider > http://www.liquid-reality.de > > Open Source Architect > http://www.talend.com > >
