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
