Hi Bill How is it going with the transactions? Are there still isseus or can you work with the current solution?
We need to decide if there is anything we should push forward for in Camel 1.5. Med venlig hilsen Claus Ibsen ...................................... Silverbullet Skovsgårdsvænget 21 8362 Hørning Tlf. +45 2962 7576 Web: www.silverbullet.dk -----Original Message----- From: tourist604 [mailto:[EMAIL PROTECTED] Sent: 11. august 2008 19:51 To: [email protected] Subject: RE: Transactions in camel: more questions (1.4.0) 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.
