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
(http://mail-archives.apache.org/mod_mbox/activemq-users/201308.mbox/%3c5218d907.3070...@agno3.eu%3E).
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.
regards
Moritz
--
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
