Hello Claus. Thank you for taking the time to reply.
I definitely realize that transactions in a mediation framework like Camel are no trivial matter. This is where distributed transaction start coming up in discussions very quickly. What I do like about Camel (and what made us push ahead with it instead of mule or others) is the simplicity of it. BTW, here is the line from org.springframework.transaction.support.DefaultTransactionDefinition which is the superclass to TransactionTemplate in spring (2.5.5): --- 255. private int propagationBehavior = PROPAGATION_REQUIRED --- (looks like the default value for the property) I just caught myself writing a long posting again :) I would like to say that a DLC would be great to have available in transaction! I did get thrown off by all the Async... types of calling in the processing pipeline though, and at the beginning I thought that it was destroying the original Spring transaction, i.e. multiple threads. As per spring docs: --- The returned TransactionStatus might represent a new or existing transaction (if there were a matching transaction in the current call stack - with the implication being that (as with J2EE transaction contexts) a TransactionStatus is associated with a **thread** of execution). --- I had since discovered the the actual thread persisted through the invocations (I am sure there was a good reason for Async interfaces all along the pipeline; I wonder if it's the generic ability to support both sync and async processing?) Last thing: my use case is simple and what makes it very common is the initial receipt of a message from ActiveMQ. From what I understand, the only way to keep the message in the queue for the duration of the processing, while using spring's and camel's jms facilities, is to keep it in a transaction. Best regards, --Bill Claus Ibsen wrote: > > Hi Bill > > If you can get the attention from some of the core committers of activemq > then you are in luck (James, Hiram etc.) > > I just wanted to write that I like your thoroughly observations. > > To clarify. You want to mix and match the transacted error handler and the > DeadLetterChannel (DLC)? > > - transacted for the jms stuff > - DLC for the retry of the http endpoint? > So the DLC is kinda nested in the transacted? > > If yes this is an interesting use-case since it would bring tremendous > value (I think). > > Ad 1) > Yes you are correct > > Ad 2) > Yes the DLC is disabled if transacted error handler (there is a JIRA > ticket for this request somewhere) > > Ad 3) > I also played with the setRollbackOnly and it also didn't work always > AFAIR. Throing a runtime exception always forced a rollback. > > > Ad 4) > Ah I didn't know the using transacted=true on ActiveMQ will default to use > spring TX with prop_required. So basically this allows to mix/match with > transacted and DLC. However not as intended I think. > > Ad 5) > Receive and Send in one TX is not as easy as one might think. Try to > search the web for this. Maybe James or Hiram can help here also with a > quick reply? > > Bill you use-case is interesting and I would love Camel to support this > out-of-the-box with a good wiki documentation for this. Please keep us > posted and maybe we should create a JIRA request for this so its better > supported in Camel. > > Issue #4 took me by surprise but I am glad to learn new stuff every day. > > > Med venlig hilsen > > Claus Ibsen > ...................................... > Silverbullet > Skovsgårdsvænget 21 > 8362 Hørning > Tlf. +45 2962 7576 > Web: www.silverbullet.dk > > > -- View this message in context: http://www.nabble.com/Transactions-in-camel%3A-more-questions-%281.4.0%29-tp18917974s22882p18930419.html Sent from the Camel - Users mailing list archive at Nabble.com.
