camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Roman Kalukiewicz <roman.kalukiew...@gmail.com>
Subject Re: Camel transactions with in-out JMS
Date Wed, 08 Apr 2009 14:41:54 GMT
Hey Claus!

Yes - I've seen it. This is the flag that allows you to do something I
already described - it allows you to turn transactions off for in-out
"jms:splited" so you are able to actually send anything. Without this option
it doesn't work at all. With this option requests are not transactional, so
you can have duplicates if original request is rolled back and redelivered.

Roman

2009/4/8 Claus Ibsen <claus.ibsen@gmail.com>

> Hi
>
> Just a quick reply.
>
> There is a trasactedInOut URI option for the JMS component. Have you
> looked at it?
>
>
> On Tue, Apr 7, 2009 at 6:29 PM, Roman Kalukiewicz
> <roman.kalukiewicz@gmail.com> wrote:
> > Hello Camel Riders!
> >
> > Let me show an example of a problem I'm working on:
> >
> > from("jms:in-queue").split(xpath("/foos/*"),
> > myAggregator).parallelProcessing().to("jms:splited");
> >
> > (this is not created with IDE, so might be worng but I hope you get the
> > idea).
> >
> > If this flow works as in-out and is transactional then it will not work
> as
> > messages are not sent to "jms:splitted" before transaction from
> > "jms:in-queue" is commited and it is not commited before response from
> > splitter is not sent back. It just hungs up.
> >
> > One solution is to make "jms:splited" non-transactional, but then we
> agree,
> > that we can have duplicates on "jms:splited" queue (we sent few messages
> > already, something fails, transaction is rolled back, we consume it once
> > again and we resend parts, that were already sent to "splited").
> >
> > I believe the proper behaviour would be to have two separate transactions
> > here:
> > * first transaction covers receive operation from in-queue, split and
> > sending requests to jms:splited and is commited when all requests to
> > 'jms:splitted' are sent
> > * second transaction covers all receive operations  from jms:splited,
> > aggregation and sending a response to jms:in-queue. Is commited when
> final
> > response is sent.
> >
> > This way we are 100% transactional and nothing can be lost and nothing
> can
> > be duplicated.
> >
> > Right now I don't believe it is possible in camel. Moreover I cannot find
> a
> > way to clearly abstract the problem so it can be unified over other
> > components (not only JMS).
> > I believe the problem is, that we try to model JMS (that is by its nature
> > in-only especially when it comes to transactions) as in-out. If we model
> it
> > as two separate in-only flows with splitter and agregator it would work
> > fine, but then we don't have a way to listen only for our responses and
> to
> > receive all responses in the same transaction.
> >
> > Maybe some of you have any thoughts on this problem?
> >
> > Cheers
> > Roman Kalukiewicz
> >
>
>
>
> --
> Claus Ibsen
> Apache Camel Committer
>
> Open Source Integration: http://fusesource.com
> Blog: http://davsclaus.blogspot.com/
> Twitter: http://twitter.com/davsclaus
> Apache Camel Reference Card:
> http://refcardz.dzone.com/refcardz/enterprise-integration
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message