cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Moritz Bechler <>
Subject Re: JTA support for JMS Transport in CXF 3.0
Date Thu, 10 Apr 2014 12:05:48 GMT
Hi Christian,

a few thoughts inline (not having looked at any of the code yet).

> I am currently working on the transaction support (resource local and
> JTA) for the JMS transport in CXF 3.
> In a chat with Dan we found that it is not fully clear what we expect
> from the transaction support. So I will do a coarse design here on the
> list and hope to get some feedback on
> what you expect and would like to see.
> The general principle on kind of "container" managed transaction support
> is to open a transaction when a message is received. Then the message is
> processed inside the transaction. If an exception happens in the
> processing the transaction is rolled back and the JMS server tries some
> redeliveries. If these all fail the message goes to the dead letter
> queue. If the processing runs without an exception the transaction and
> so the message will be committed.
> Service side:
> - Support transactions only for One Way messaging. I think for request
> reply there is always a client on the other side who can retry when a
> message is lost and the client also wants some feedback about errors on
> the server side.
This sounded interesting at first sight (to allow transparent 
retry/failover) but propably will only lead to recv or transaction 
timeout for most deployments.
Still, might be a nice to have to actually have a chance to get a 
transaction allowing for rollback, if one were to make such experiments, 
and have one started automatically. But then an error reply should be 
committed in any case if not explicitly rolled back.

> - For one way exchanges I propose to roll back on any exceptions as it
> is the simplest case. We might also support to permanently fail a
> message on things like invalid xml as this will probably also fail the
> next time. It is difficult to correctly specify when to roll back and
> when to fail in this case.
Checked exceptions from the service code should imho qualify as 
persistent errors (if they are even allowed).

CXF internal exceptions (xml/jaxb/validation errors) are indeed 
difficult, whether these may be recoverable at all heavily depends on 
the deployment so I agree this should be configurable.

The same holds for RuntimeExceptions thrown by service code. Some 
implementations go with RuntimeException for rollback but this is still 
very broad. Imho, this behavior should also be configurable (per service 
if possible) plus there should be a custom exception type which always 
triggers rollback.

> - I tested the low level MessageListenerContainer I created with
> resource local and JTA transactions. JTA only seems to work if I use a
> polling approach. I am not sure if this is expected.
I also ran into this with ActiveMQ, their consumer implementation does 
not allow this. I asked about this on activemq-users quite a while ago 
but got no response 

> Client Side:
> - No special handling on conduit side
> - If the user uses a JCA Pooling Connection Factory the session would
> automatically take part in any user transactions. For one way messaging
> this is probably a good thing. For request reply this is rather not what
> we want as the message would only be sent after the commit. As the
> conduit waits for the reply the message then would never be sent out and
> we run into a timeout.
Any chance to at least add something (callback?) that allows to commit 
and restart a transaction at the right point? With implementations 
closely following the spec, when using JTA the client session will 
forcibly (if you do not create a second non-transacted 
ConnectionFactory) be part of an active transaction (e.g. when calling a 
service inside another service) so this will be necessary.



AgNO3 GmbH & Co. KG, Sitz Tübingen, Amtsgericht Stuttgart HRA 728731
Persönlich haftend:
Metagesellschaft mbH, Sitz Tübingen, Amtsgericht Stuttgart HRB 744820,
Vertreten durch Joachim Keltsch

View raw message