couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Damien Katz <dam...@apache.org>
Subject Re: couchdb transactions changes
Date Sun, 08 Feb 2009 04:37:47 GMT

On Feb 7, 2009, at 9:37 PM, Antony Blakey wrote:

>
> On 08/02/2009, at 12:05 PM, Damien Katz wrote:
>
>> But if the replication doesn't complete, like in the middle you  
>> lose your connection, then the downstream db is in an inconsistent  
>> state and will be until you regain the connection and complete the  
>> replication.
>
> Sure, that's OK. In my case there are potentially millions of  
> 'downstreams'.
>
>> And its not just the downstream dbs that can't be used during  
>> active or interrupted replication, it's the central db as well. If  
>> you want to update it, you'll have to shut down access while  
>> waiting for any in progress replications to complete, then perform  
>> the update then reopen replication access.
>
> I can't see why this needs to be the case. The fact that there are  
> peers that have an incomplete replication doesn't stop the master  
> taking updates - iff the updates to the master are multi-document  
> ACID.

Because during downstream replication it may get just some of the  
documents from a commit that happens during replication. Replication  
isn't all or nothing, and it doesn't know about transactions

>
>
> In my case, replication can occur from any peer that isn't itself  
> replicating, and has completed a valid replication cycle.
>
> The key thing being, even with multiple writers i.e. symmetric  
> peers, that replication occurs between nodes that are themselves  
> consistent e.g. conflicts are never replicated, they are only the  
> result of replication, and the node is locked until a replication  
> cycle completes (or is abandoned, which is a separate issue that I  
> have to address).

The thing is, to avoid all conflicts and inconsistent states, you must  
read lock the source db during active replication and write lock the  
target database pretty much until the replication is complete.  
Otherwise, you'll will get inconsistent states.

Does each user get their own local instance of the database? If that's  
the case, you don't need multi-document conflict detection. You just  
lock the user out of the database during replication and lock out  
replication while the user is using it. And it sounds like you already  
have that.

>
>
> Am I missing something?

.

>
>
> 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
>
>


Mime
View raw message