couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Damien Katz <>
Subject Re: couchdb transactions changes
Date Sun, 08 Feb 2009 01:16:22 GMT

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.


> 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

View raw message