[rabbitmq-discuss] AMQP & Python Write-Up

Thu Jan 15 11:43:04 GMT 2009

Hi Ben
you are quite correct with the central tenet.  It's the I of ACID.

My pov is that, as someone who controls the use of messaging systems,  
I'd rather have a mechanism that enforces good behaviour than have to  
rely on programmatic style. This is even if I'm writing the code  
myself. I want it right (and simple) before I want it fast, as 'right'  
is often fast enough, anyway. (note I'm talking here about the code  
using rabbitMQ, not rabbitMQ itself).  I expect much sloppier code  
using the messaging layer than in the messaging layer. That's why  
kernel code costs 10x as much as business application level code.

Surely it's more difficult to get interleaved updates if the work is  
carried out in processes rather than threads, isn't it?  If it's  
possible to abuse the command isolation, even using processes, is  
there a way for me to enforce the isolation?

Tim
On 14 Jan 2009, at 23:12, Ben Hood wrote:

>
> Tim,
>
> On Wed, Jan 14, 2009 at 11:04 PM, Tim Coote <tim+rabbitmq.com at coote.org 
> > wrote:
>>
> Be that as it may, the central tenant is to not interleave different
> command streams in one channel.
>
> Whether this is done by thread or process confinement (or even if you
> are a kernel hacker and you know that in reality there is no such
> thing as a thread or a process) is irrelevant.
>
> The broker has no visibility into what client side objects are shared,
> nor does it care.
>
> The broker is just sitting on the other end of a wire with the mere
> expectation that each individual stream of commands is stateful and
> coherent.
>
> HTH,
>
> Ben
>

Tim Coote
tim at coote.org
vincit veritas