camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Marat Bedretdinov (JIRA)" <j...@apache.org>
Subject [jira] Issue Comment Edited: (CAMEL-2001) Transactions do not work properly with JMS producer endpoint when processing InOut exchanges
Date Thu, 10 Sep 2009 03:36:13 GMT

    [ https://issues.apache.org/activemq/browse/CAMEL-2001?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=54110#action_54110
] 

Marat Bedretdinov edited comment on CAMEL-2001 at 9/9/09 8:35 PM:
------------------------------------------------------------------

Fintan,

I haven't looked at the way transactedInOut=false has been implemented but I'd like to get
a few clarifications on what you said.

1. On one hand you say that "Meaningful transactions are generally used to bracket multiple
(i.e. >1) updates of a persistent resource."  Then you say "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." 

So should I understand that you want to control how many messages per transaction a given
route would consume and then produce, or it would be okay to consumer and produce a single
message within context of a single transaction?

2. But speaking more generally I'm not convinced that an InOut exchange pattern should be
transacted. See the consumer that collects the reply of an InOut exchange has a its life cycle
constrained by the life cycle of the producer that sent a request message. 

So should the producer succeed at producing the request, then committing the request and then
should the router then crash the reply consumer will never be restored and the reply never
received and forwarded.

This is also true for the client application initiating a two way exchange. If application
crashes in the middle of the request the reply will be lost to this application.

In my mind there is a way to implement this, but requires a lot more work than just changing
the camel jms component.

3. Lastly it is currently possible to achieve meaningful transactional behavior with two transacted
InOnly routes (cross broker including) and application doing the correlation if a request/reply
pattern is what is required.

      was (Author: marat):
    Fintan,

I haven't looked at the way transactedInOut=false has been implemented but I'd like to get
a few clarifications on what you said.

1. On one hand you say that "Meaningful transactions are generally used to bracket multiple
(i.e. >1) updates of a persistent resource."  Then you say "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." 

So should I understand that you want to control how many messages per transaction a given
route would consume and then produce, or it would be okay to consumer and produce a single
message within context of a single transaction?

But speaking more generally I'm not convinced that an InOut exchange pattern should be transacted.
See the consumer that collects the reply of an InOut exchange has a its life cycle constrained
by the life cycle of the producer that sent a request message. 

So should the producer succeed at producing the request, then committing the request and then
should the router then crash the reply consumer will never be restored and the reply never
received and forwarded.

This is also true for the client application initiating a two way exchange. If application
crashes in the middle of the request the reply will be lost to this application.

In my mind there is a way to implement this, but requires a lot more work than just changing
the camel jms component.

Lastly it is currently possible to achieve meaningful transactional behavior with two transacted
InOnly routes (cross broker including) and application doing the correlation if a request/reply
pattern is what is required.
  
> 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: Future
>
>
> 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.


Mime
View raw message