On Mon, Feb 9, 2009 at 6:48 PM, Antony Blakey <antony.bla...@gmail.com> wrote: > > On 10/02/2009, at 9:44 AM, Damien Katz wrote: > >> >> On Feb 9, 2009, at 5:59 PM, Antony Blakey wrote: >> >>> OK, I give up. >>> >>> Given compaction and/or revision pruning (as Damien has proposed in >>> another thread), even generic 'Eventual Consistency' isn't guaranteed. >> >> Revision stemming is 100% optional, and the compaction works the same as >> it did 0.8.0. I'm not sure why you think 'Eventual Consistency' isn't >> guaranteed. > > Because it depends on a steady state that may never be reached as long as > modification stays ahead of replication - the 'eventual' point might be > always ahead of the shared state. >
Alas it is true, if you have a system that has operating characteristics that involved a write load that far outweighs the read load you actually do break the assumptions that are plastered all over the documentation. > Compaction and revision stemming (which is required to avoid unbounded > growth) make intermediate states inconsistent because they can delete either > the data of a document rev or the document rev itself. In the face of > compaction, it's possible for consistency to only be achieved when the > replication reaches the same MVCC commit point that the compaction was > operating against. Revision stemming has a similar effect, although it has > the further issue of being automatic i.e. not scheduled. > > That's ignoring replication failure, either temporary or permanent, which > further complicates the picture. Given that intermediate states are not > necessarily consistent, anything that leaves you in an intermediate state > without a way forward, repudiates the guarantee of Eventual Consistency. > I'm pretty sure the rest of this is wrong though. > Antony Blakey > ------------- > CTO, Linkuistics Pty Ltd > Ph: 0438 840 787 > > Nothing is really work unless you would rather be doing something else. > -- J. M. Barre > > > HTH, Paul Davis
