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" <[email protected]> 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" <[email protected]> > 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 >> >>
