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