[rabbitmq-discuss] Making persistence simpler (Was: AMQP & Python Write-Up)
sustrik at imatix.com
Sat Jan 17 20:51:14 GMT 2009
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.
More information about the rabbitmq-discuss