cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Schneider <ch...@die-schneider.net>
Subject JTA support for JMS Transport in CXF 3.0
Date Thu, 10 Apr 2014 08:38:46 GMT
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


-- 
Christian Schneider
http://www.liquid-reality.de

Open Source Architect
http://www.talend.com


Mime
View raw message