cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sergey Beryozkin <sberyoz...@gmail.com>
Subject Re: JTA support for JMS Transport in CXF 3.0
Date Fri, 11 Apr 2014 10:43:14 GMT
Hi Christian

First of all: the way you've refactored the transport so far is perfect :-).

I'd only suggest that we try and release 3.0.0 first, may be do some of 
your ideas in the next week or two (to get some initial transaction 
support done) and immediately continue in 3.0.1. JAX-RS users can not 
get a final 3.0.0 release and in May it will be the 1st anniversary of 
JAX-RS 2.0 release, so I'm hoping they can see final 3.0.0 before May :-)

Sorry it is not about JMS, I agree we need to do it right with respect 
to the transactions support, but hope we can split thos work across 
consecutive releases

Cheers, Sergey



On 10/04/14 09:38, Christian Schneider wrote:
> Hi All,
>
> 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.
> - 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.
> - 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.
>
> 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.
>
> I would be happy to hear from you what you would expect from transaction
> support and what you think about the ideas formulated here. If any of
> you has first hand experience with JMS transactions (especially JTA) I
> would also like to hear from your experiences.
>
> Christian
>
>



Mime
View raw message