[rabbitmq-discuss] Fwd: question on the faq

Wed Jan 7 12:31:23 GMT 2009

Hi Ben
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
> work?
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.
>
> Ben
>

Tim Coote
tim at coote.org
vincit veritas