[rabbitmq-discuss] AMQP & Python Write-Up
tim+rabbitmq.com at coote.org
Thu Jan 15 11:43:04 GMT 2009
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?
On 14 Jan 2009, at 23:12, Ben Hood wrote:
> 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
tim at coote.org
More information about the rabbitmq-discuss