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.
-Damien
Antony Blakey
--------------------------
CTO, Linkuistics Pty Ltd
Ph: 0438 840 787
Hi, I'd like to do $THING. I know that $SOLUTION_A and $SOLUTION_B
will do it very easily and for a very reasonable price, but I don't
want to use $SOLUTION_A or $SOLUTION_B because $VAGUE_REASON and
$CONTRADICTORY_REASON. Instead, I'd like your under-informed ideas
on how to achieve my $POORLY_CONCEIVED_AMBITIONS using Linux, duct
tape, an iPod, and hours and hours of my precious time.
-- Slashdot response to an enquiry
