[
https://issues.apache.org/activemq/browse/CAMEL-2001?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=61178#action_61178
]
Fintan Bolton commented on CAMEL-2001:
--------------------------------------
I am out of the office from 11th August until 18th August, 2010. I will respond
to your mail when I return on August 19th.
> Transactions do not work properly with JMS producer endpoint when processing
> InOut exchanges
> --------------------------------------------------------------------------------------------
>
> Key: CAMEL-2001
> URL: https://issues.apache.org/activemq/browse/CAMEL-2001
> Project: Apache Camel
> Issue Type: Bug
> Components: camel-jms
> Affects Versions: 2.0.0
> Reporter: Fintan Bolton
> Fix For: 2.5.0
>
>
> You cannot really use transactions with a JMS producer endpoint when
> processing _InOut_ exchanges. Depending on the scenario, the route either
> hangs or the implemented behavior is not very useful.
> Here is a summary of the current (not very useful) behavior:
> After experimenting with JMS transacted endpoints for a bit and looking at
> the source, here is what I found the behavior to be for JMS producer
> endpoints:
> # On the request leg (sending the JMS message), if there is no existing
> transaction context, the producer will either create a transaction for
> sending the message (if {{transactedInOut=true}} or not (if
> {{transactedInOut=false}}). In any case, since the transaction only lasts as
> long as it takes to push the message onto the outoing queue, it is not
> particularly interesting. Meaningful transactions are generally used to
> bracket multiple (i.e. >1) updates of a persistent resource.
> # On the request leg, if there *is* an existing transaction context, the
> producer joins the current transaction (irrespective of the value of
> {{transactedInOut}}), provisionally writes the message to the outgoing queue,
> and then starts waiting for the reply. In this case, the route hangs, because
> the send is never committed.
> # On the reply leg, the message is received in a separate thread. This step
> is transactional, but the transaction ends as soon as the message has been
> pulled off the queue, so it is also not very interesting.
> Here is what I think would be useful behavior for a JMS producer endpoint:
> # On the request leg, if there is an existing transaction context, the
> producer joins the current transaction, provisionally writes the message to
> the outgoing queue, and then *commits* the current transaction directly
> afterwards. This prevents the route from hanging. *Note:* There is some code
> in the {{CamelJmsTemplate}} class looks like it was intended to do this, but
> it currently does not work. See child issue for more details.
> # On the reply leg, create a new transaction in the main thread that includes
> the action of pulling the reply off the incoming queue. This would require
> that the reply be received in the main thread, not a sub-thread (as
> currently). Subsequent nodes in the route could then participate in this
> transaction. Admittedly, this would be a tricky feature to implement, because
> it would involve making a big change to the producer's threading model.
> I'm shortly going to add a couple of child JIRAs here to explain some related
> issues.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
