On 8/22/06, Terry Cox <[EMAIL PROTECTED]> wrote:
Hi,
Having read the page on transactions, I am left with a number of
questions, so perhaps we can discuss these and push the answers back
onto the site.
My understanding is that using the Seda flow, transactions are
propagated between components utilising synchronous calls, making it
possible to roll back a series of steps. Since the message exchanges are
non-persistent, failure of the container will lead to loss of data.
Does the transaction have to be created programmatically, or can
components be configured to generate declarative transactions?
You should configure the autoEnlistInTransaction flag to true on the
container so that each time a JBI exchange is sent, it will be enlisted
in the current transaction.
Transactions are not created by default. The only component being able
to start transactions is the servicemix-jms when used with JCA.
Note that the JCA flow will also start transactions.
You may be able to leverage spring features to automatically
start transactions, i guess it will depend on the components you use.
ST and JMS flows don't support transactions.
True, but you can configure mutiple flows.
The JCA flow is using JMS to provide message persistence, so effectively
each message exchange is a JMS queue. This implies a JMS-style
transactional contract, so a message may be placed into an exchange as
part of the transaction of component A, but that transaction must commit
before the exchange can proceed. Component B may then receive the
message however this will not be within a transaction unless one is
somehow created declaratively by the container?
The transactional boundaries will depend if the component use send or
sendSync. If you use send in a transaction, the exchange will be processed
by the JCA flow, which is the only one able to handle this QoS. If you
use sendSync, then the SEDA flow will be used.
Assuming this were the case, if Component B threw an exception, would
the message be rolled back to the MessageExchange and then subsequently
be re-delivered as part of a new transaction?
If the container fails during a transaction, are messages heuristically
rolled back and re-delivered upon restart?
(I assume messages are only persistent if marked Robust?)
RobustInOnly is about being able to send back a fault to the consumer.
Faults and Errors are different, as fault should indicate business logic
error or bad messages. They should be unrecoverable problems
due to the message itself. Recoverable errors such as connection problems,
timeouts, aso, should use Errors.
There is no centralized point to handle transaction rollback / redelivery,
but std jbi components will catch all exceptions and mark the transaction
has rollback if there is an ongoing transaction and the exception is a runtime
exception.
If Component B is stateful (say an orchestration component that passes a
message through several external processes), then that state must be
persisted and recovered in concert with the exchanges. Is there any
example of this behaviour within the ServiceMix source?
No :(
Many thanks,
Terry
--
Cheers,
Guillaume Nodet
