[rabbitmq-discuss] Fwd: question on the faq
tim+rabbitmq.com at coote.org
Wed Jan 7 12:31:23 GMT 2009
On 7 Jan 2009, at 11:34, Ben Hood wrote:
> So you intend to keep an exclusive lock on the entities that you
> requesting from the downstream system for the duration of the unit of
Not sure what you mean here? why do I need any exclusive lock? This
sounds like a scale issue, in general, which will drive the
interaction process that's feasible. All I want is that what my app
understands is the state of the world (including entities that are
invented to plan the future or model uncertainty. Without this
guarantee, I don't see how the app works reliably anyway.
If the resource that my app's looking to 'get a lock on' gets
consumed, the transaction aborts. What's the problem?
> If those are you requirements then my initial feeling is that a
> messaging system like Rabbit would be a poor fit for your use case.
> This is because to make the requests visible to the downstream system
> before the transaction commits, all of those systems would have to
> participate in the same transaction. To do this, you would have to
> extend the transactional context to each participant, which is not
> possible (in Rabbit) without any application level code to propagate
> the distributed consensus.
I agree with your analysis of my example, if the option is available
to avoid a messaging based application idiom. However, my original
post was only to understand/request clarity on the ways that the term
Transaction is used in the FAQ. I think that its use is confusing to
some people coming to the technology domain for the first time,
especially if they've got a background in transactional systems.
That's my pov, I'm happy if the community agrees - even more so if it
acts and I'm right - and I won't lose any sleep if it doesn't. I think
that the DTX class is closer to what I'd expected the term to mean.
> Hence my recommendation is to either take the example that Carl wrote
> yesterday or use middleware that is less asynchronous.
For the type of problem that I outline, I think that the best approach
is to wrap the messaging plumbing as a transactional interface. My
reasoning is that I want cheap coders to write my apps and I don't
want them experimenting with asynchronous models in my business
applications :-) If I cannot get application level transactional
semantics from a Service, I'd argue that the Service should be in
constant review if it's in my SOA, as a prime intent of SOA is to
reduce the ownership costs of applications.
> BTW Carl - would it be possible to have a look at the code that you
> wrote for Tim? It may clarify my lack of understanding.
tim at coote.org
More information about the rabbitmq-discuss