[
https://issues.apache.org/activemq/browse/CAMEL-634?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=43805#action_43805
]
Marat Bedretdinov commented on CAMEL-634:
-----------------------------------------
Claus:
> Could you provide a unit test for the new class ExchangeProperty also?
Working on it.
> I am wondering if we should introduce an method on Exchange interface that
> returns whether this exchange is in transacted mode or not?
Sure. Will add that
> According to the spring transaction programmatic stuff you can set the
> rollback only status. And I am wondering if we should do this also when we do
> the rollback by throwing the wrapped exception?
I can add that, however it has no effect on JMS tx being rolled back as there
is a bug in the way tx management is implemented in Spring's JMS
DefaultListenerContainer
> We are adding a TRANSACTED property on the Exchange that is never removed.
That's not quite true I believe. As far as I can tell an Exchange lifespan is a
single call flow. So if this call flow is transacted then this property is
installed on it. Once this Exchange instance is freed so are its properties.
> As this class is in org.apache.camel package I do think it should have
> javadoc stating its purpose.
Working on that as well.
> DeadLetterChannel default redelivery policy eclipsed expected transactional
> behaviour in a transacted route
> -----------------------------------------------------------------------------------------------------------
>
> Key: CAMEL-634
> URL: https://issues.apache.org/activemq/browse/CAMEL-634
> Project: Apache Camel
> Issue Type: Bug
> Components: camel-core, camel-jms
> Affects Versions: 1.4.0
> Reporter: Marat Bedretdinov
> Assignee: Claus Ibsen
> Fix For: 1.5.0
>
> Attachments: tx.fix.2008-06-24-16-54.patch
>
>
> Camel routes get a DLC processor with a redelivery policy, which defaults to
> redeliverying a message to a destination processor up to 6 times. In case of
> a transacted route it is preferable that DLC's delivery policy be reset to a
> single attempt, so that a fan-out transacted route would not hold tx locks on
> destinations for too long.
> The DLC's default redelivery policy has also made transactional tests not
> really testing tx behavior of Camel Components backed runtimes (jms brokers,
> etc), rather DLC would catch the exception and try to redeliver the message
> to destination processor and not letting the components to rollback native
> transactions initiated by components backed runtimes (jms, db)
> The attached patch installs a property into Camel Exchange that indicates
> weather a route is transacted. This is done in
> org.apache.camel.spring.spi.TransactionInterceptor.java
> DLC then checks if the flow is transacted and sets its redelivery policy to 1
> With this change JMS transactions are actually rolled back and messages are
> put back into the queue and then consumed again, verifying that brokers
> support transactions and can redeliver messages into Camel routes that were
> previously rolled back.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
