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 <ja...@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" <ja...@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" <ch...@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 >>> >>>
