[rabbitmq-discuss] Making persistence simpler (Was: AMQP & Python Write-Up)

[Martin Sustrik]

Holger Hoffstätte wrote:
> Martin Sustrik wrote:
>> Specifying persistence on per-message basis makes no sense of course. 
> 
> "Of course"? I'd like to hear why you think that is so obvious, because I
> don't think it is. :)
> Explicitly required persistence can be seen as just another orthogonal
> property to transactionality, lifetime or other QoS requirements.
> Enforcing these properties for every consumer up-front might admittedly
> make the life of a broker implementer easier, but at the cost of going
> against the client-driven nature and an architecture with intelligent and
> responsible endpoints (bottom up). You can always superimpose centralized
> decisions over this (e.g. through consistent configuration), but not the
> other way.

True, but the fact that you can do something doesn't necessarily mean 
you should do it.

I would say that clearly separating dataflows with different semantics 
is a matter of sane design. If I had to pass both persistent and 
transient messages between two endpoints (say trades & market data) I 
would define each of them as a separate "path" that way reducing 
possible interactions between persistent and transient messages and 
avoiding undefined behaviour in case of failover, where transient 
messages are lost while persistent messages are replayed.

Martin