On 08/02/2009, at 11:46 AM, Damien Katz wrote:
On Feb 7, 2009, at 6:14 PM, Antony Blakey wrote:
On 08/02/2009, at 9:35 AM, Damien Katz wrote:
I think this works in situations where you have only a single
machine (no replication, no failover), or your app can have read
only slaves nodes where readers don't care about db consistency
(but still no failover). I'm not sure that fits many real world
use cases.
If you have read-only slaves, then they won't be inconsistent
outside of a replication. This is my current deployment model, with
a very large number of users, where every user is potentially
running a copy of 'Desktop CouchDB' (cf the contract I posted).
This is CouchDB as Notes Client, not as a server per-se.
During replication, you don't get any sort of interdocument
consistency guarantee or even update ordering. During replication,
the clients will see random updates until the replication is fully
complete. If the downstream clients lose their connection halfway
during an replication, they won't have a consistent database.
Sure, but this isn't an issue if your app allows for a replication-
mode that is exclusive to normal application mode i.e. doesn't switch
until it gets a completed replication.
I think the issue you are addressing will only occur if replication is
concurrent with 'normal' operation. For applications the require
consistency, this need not be the case.
Antony Blakey
--------------------------
CTO, Linkuistics Pty Ltd
Ph: 0438 840 787
The greatest challenge to any thinker is stating the problem in a way
that will allow a solution
-- Bertrand Russell
