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 -----Original Message----- From: tourist604 [mailto:[EMAIL PROTECTED] Sent: 11. august 2008 01:01 To: [email protected] Subject: Transactions in camel: more questions (1.4.0) Hi, I have been trying to figure out how to use transactions in camel. My original requirements are simple: While in transaction, do: 1. Consume a JMS message 2. Process it and route it to an http endpoint 3. If http resets connection or returns with invalid status, 4. Retry the message using DeadLetterChannel facilities and exception based handling and re-route, if all fails, elsewhere. While trying to figure out how to use transaction consumption of JMS messages in camel, I have found this post in the forum: http://www.nabble.com/JMS-Transactions---How-To-td15168958s22882.html#a15168958 This post led me to believe that I need to add this to my route IN ADDITION to specifying the JMSComponent as transactional in the spring context: --- spring context snippet: --- <bean id="activemq" class="org.apache.camel.component.jms.JmsComponent"> <property name="connectionFactory"> <ref bean="jmsConnectionFactory" /> </property> <property name="transactionManager"> <ref bean="jmsTransactionManager" /> </property> <property name="transacted"> <value>true</value> </property> </bean> --- end of spring contxt snippet: --- --- route definition snippet: --- Policy required = new SpringTransactionPolicy(bean( TransactionTemplate.class, "PROPAGATION_REQUIRED")); from( "activemq:myqueue" ).policy( required )... --- end of route definition snippet ---- The configuration above fails in one major way: it doesn't allow me to use the DeadLetterChannel to handle errors. After spending a few days battling with this configuration, I have come to the following conclusions: 1. Attaching a "PROPAGATION_REQUIRED" policy to the route does not initiate the transaction. The transaction is initiated by JmsComponent; in fact, it's initiated by Spring itself via the Message-Driven POJO support. 2. Attaching this policy will cause a flag to be set on the exchange which will make DeadLetterChannel skip altogether, thereby foregoing its (in my opinion great!!!) mechanism of discriminately handling different exceptions in different ways and re-routing the message elsewhere. The errorHandler cannot be placed after the transactional policy in the route; it will always be placed before by the route "start" code. 3. On error, org.apache.camel.spring.spi.TransactionInterceptor which is injected by adding the PROPAGATION_REQUIRED policy returns with 3 conditions which may be interpreted as rolling back the transaction: line: 128 if (rce != null) { redeliveryData.previousRollback = true; if (activeTx) { status.setRollbackOnly(); LOG.debug("Transaction rollback"); } throw rce; } a) status.setRollbackOnly(): I tried skipping this flag, and transaction still rolled back so it appears to be ineffectual b) "throw rce" will cause the TransactionTemplate to perform a rollback c) the original exchange may contain an exception which will cause the message listener to re-throw it. (the above 3 things may be confusing to anyone trying to debug the transactional handling) 4. NOT ADDING the policy to the route still makes the route operate within the transaction initated by the JmsComponent and spring **AND** DeadLetterChannel is happily available to handle your retries and re-routing WITHIN the original transaction. 5. If I **send** (while re-routing) a message within the same route using the same JmsComponent, configured with the same transaction manager, the default "PROPAGATION_REQUIRED" propagation behaviour in spring's TransactionTemplate will cause this operation to be enlisted within the original transaction initiated by the JMS consumer thus rendering the whole route to operate within the same transaction (here we are using the same transactional data sources, i.e. the same activemq broker, so no distributed semantics). Can anyone confirm the validity of these assumptions? I would greatly appreciate it as the transactional behaviour in camel is a critical aspect of a our camel-based integration solution. Thanks, --Bill -- View this message in context: http://www.nabble.com/Transactions-in-camel%3A-more-questions-%281.4.0%29-tp18917974s22882p18917974.html Sent from the Camel - Users mailing list archive at Nabble.com.
