cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason Pell <ja...@pellcorp.com>
Subject Re: Cxf 2.7 JMS destination change what happens when checked exception is thrown from service impl
Date Fri, 05 Dec 2014 01:42:49 GMT
Ok - in my local tests with both websphere mq and active mq, the trans test
appears to be doing the right thing, but I am unsure why.  I don't
understand why the sessions are not the same.

However when I am debugging the
org.apache.cxf.systest.jms.tx.JMSTransactionClientServerTest in
cxf-systests-transport-jm the trans test is false because the sessions
match.

I know I must be missing something, and I will continue to debug it to see
if I can figure it out, but perhaps someone might have some insight to
assist me

On Fri, Dec 5, 2014 at 11:20 AM, Jason Pell <jason@pellcorp.com> wrote:

> Hi Christian,
>
> While writing a test case for the transaction case for request / response
> I came across something else in the code I am confused about.
>
> The JMSDestination has a check of the following:
>
> boolean trans = resourceHolder == null ||
> !resourceHolder.containsSession(session);
>
> So if the resourceHolder is not found or the resource holder does not have
> the session, then there is no transaction.  Is this correct?
>
> I would have thought the opposite would have been true:
>
> boolean trans = resourceHolder != null &&
> resourceHolder.containsSession(session);
>
> Can you comment on this?
>
>
> On Fri, Dec 5, 2014 at 9:26 AM, Jason Pell <jason@pellcorp.com> wrote:
>
>> Very annoyed with myself that I did not check the transaction support for
>> request response till now. Was on my list of todos. Now I am going to have
>> to depend on 2.7.15 snapahot.
>>
>> I need guaranteed delivery even for request response as my client is not
>> expecting to have to retry and the message needs to survive a server crash
>> or db issue.
>>
>> I am not going to use xa transactions though. Will be enough to use good
>> old jms transaction manager support.
>> On 05/12/2014 9:13 AM, "Jason Pell" <jason@pellcorp.com> wrote:
>>
>>> I check that the exception cause is instanceof Exception and not
>>> propogate. Otherwise the old functionality applies.
>>> On 05/12/2014 8:41 AM, "Christian Schneider" <chris@die-schneider.net>
>>> wrote:
>>>
>>>> I think one thing to consider is handling of java.lang.Error. These are
>>>> not of type Exception and not of type RuntimeException. As they are not
>>>> expected a Rollback may be apropriate but I am not sure.
>>>>
>>>> As far as I can remember the reason why I did not implement a more
>>>> sophisticated behaviour till now is that I never actually used transactions
>>>> for Request/Reply.
>>>> In one way messaging transactions are essential as the caller has to be
>>>> sure that messages do not get lost.
>>>> In request/reply there is always someone on the other side listening
>>>> for the reply. If no reply comes he can and probably will retry. So there
>>>> is much less pressure to use transactions at all.
>>>>
>>>> Christian
>>>>
>>>>
>>>> On 04.12.2014 18:09, Jason Pell wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> I would like to change the existing behavior of JMS destination to NOT
>>>>> rollback the transaction if a checked exception is encountered.
>>>>>
>>>>> https://issues.apache.org/jira/browse/CXF-6136
>>>>>
>>>>> Christian suggested I post an email to this list to give everyone an
>>>>> opportunity to agree or disagree with my proposed changes.
>>>>>
>>>>> Currently if a transaction manager is registered (even just a JMS
>>>>> transaction manager) and an exception is thrown by an impl method the
>>>>> JMS
>>>>> message will be rolled back.
>>>>>
>>>>> There is currently no distinction made. Even if I throw a business soap
>>>>> fault its still going to roll back the message.
>>>>>
>>>>> I would like to add code to JMS Destination to no longer propagate
>>>>> checked
>>>>> exceptions which will result in the delivery of a soap fault response
>>>>> to
>>>>> the JMS reply queue.
>>>>>
>>>>> Christian has suggested we could make this change without a backwards
>>>>> compatible config entry in JMSConfiguration. I am happy to add a config
>>>>> entry to maintain legacy behavior..
>>>>>
>>>>> Thoughts?
>>>>>
>>>>>
>>>>
>>>> --
>>>> Christian Schneider
>>>> http://www.liquid-reality.de
>>>>
>>>> Open Source Architect
>>>> http://www.talend.com
>>>>
>>>>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message