Mailing-List: contact dev-help@cxf.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cxf.apache.org
Received-SPF: pass (nike.apache.org: domain of cschneider111@gmail.com
 designates 74.125.82.48 as permitted sender)
Sender: Christian Schneider <cschneider111@gmail.com>
Message-ID: <54817E15.5050709@die-schneider.net>
Date: Fri, 05 Dec 2014 10:42:45 +0100
From: Christian Schneider <chris@die-schneider.net>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
 rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: dev@cxf.apache.org
Subject: Re: Cxf 2.7 JMS destination change what happens when checked
 exception
 is thrown from service impl
References: 
 <CACBZuv7PkwPx17TGGJSypZwSSy=Uo8JX0C0VdYLqK+XNe=fAdw@mail.gmail.com>
	<CACBZuv4GUkxdPFE3h+TvPk75hkWH4vxHB2xuKbMpJ6J_Md_RmA@mail.gmail.com>
	<CACBZuv57A37sD7f_5SL5=oVeiD3+JC4ghoC3L14JkFtW8jfAjw@mail.gmail.com>
	<5480D4BF.7060408@die-schneider.net>
	<CACBZuv7P=tT9OrQBJ+82qAZT3yxNmxEX43mdRBR_jSrgDXmG0g@mail.gmail.com>
	<CACBZuv7LbjHaJxH-ZogvD9XF_zT1i_JuGfuGN5ebpiR3XY7M6g@mail.gmail.com>
	<CACBZuv7c=frPKZxgJ4hfRo8nKiNM1Ju=jf47Lr26znCOBR_s+A@mail.gmail.com>
	<CACBZuv4LTTW_7d8xvMeKXWZ+wciD_16mABvFhttCkRrhPYOJdg@mail.gmail.com>
	<CACBZuv6rhdmJd_j5BQCAPsYKT0cHaQTAH_Y4uMfXk19L9BVXRg@mail.gmail.com>
	<CACBZuv4FXWdWF8kk_4vh1Xpo65q556UcYpYttEF-E2O-Tv1gmw@mail.gmail.com>
 <CACBZuv7VtzZntGLA0rjpw=1Wh-RZfYcDwiAP29vnwN+Uff13tg@mail.gmail.com>
In-Reply-To: 
 <CACBZuv7VtzZntGLA0rjpw=1Wh-RZfYcDwiAP29vnwN+Uff13tg@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit

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