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
