couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Wout Mertens <>
Subject Re: [user] Re: reserving resources in Couch
Date Fri, 13 Feb 2009 12:55:07 GMT
On Feb 13, 2009, at 12:14 PM, Jan Lehnardt wrote:

> On 13 Feb 2009, at 11:59, Wout Mertens wrote:
>> Can I count on this always being true for a single-node CouchDB?
> Yup.
>> What about a replicating CouchDB cloud where competing instances (A  
>> and B) connect to the same CouchDB?
> Not sure how this scenario is different from the single-node CouchDB
> instance.

Me neither, is why I asked ;-) Ok so it's the same.

>> And, just out of interest, what would be a good way to do this if  
>> you have competing instances connecting to different CouchDBs in a  
>> replicating cloud? I think you'd have to make replication a part of  
>> the reservation process, right?
> Say you have two nodes and you reserve resource X on node 1
> with client A and resource X on node 2 with client B. X on 1 and 2
> will have different revision ids. On replication, this creates a  
> conflict.
> Automatic conflict resolution will pick one of the revisions and  
> save it
> as the lastest revision. All nodes participating in replication will  
> pick
> the same winning revision. The losing revision is stored as a previous
> revision. So you are guaranteed that only one process effectively can
> hold the lock after replication.

Ok so if that happens you need to make sure your app knows that it can  
have its lock revoked by replication. Looks like forcing per-document  
masters like Paul proposes seems the way to go (but then you have to  
be careful about node outages).

Ok, thanks for the info, I get it now!


View raw message