Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@couchdb.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
Message-Id: <A4D7A042-F002-40E5-B100-6878CDC4315A@apache.org>
From: Jan Lehnardt <jan@apache.org>
To: user@couchdb.apache.org
In-Reply-To: <12E12F65-1E36-4BF6-A3D7-868002B13084@cisco.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v930.3)
Subject: Re: [user]  Re: reserving resources in Couch
Date: Fri, 13 Feb 2009 12:14:36 +0100
References: <7528BFCF-2533-4A6F-AE60-C6968E219F88@cisco.com>
 <19C1C5D0-DC35-4FB0-B582-D40E3F7AFA75@blit.com>
 <12E12F65-1E36-4BF6-A3D7-868002B13084@cisco.com>


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.


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


Cheers
Jan
--

>
>
> Wout.
>
> On Feb 12, 2009, at 8:56 PM, Troy Kruthoff wrote:
>
>> If I understand you correctly, what you need is already baked in  
>> with revision #'s.
>>
>> 1) Get a doc that is not assigned a resource
>> 2) Flag the doc as being in-use and then save it.
>> 2a)  If the save fails because of conflict, you can then verify the  
>> new rev is in use and forget about it
>> 2b)  If save is success, you know that process has secured the "in- 
>> use" lock
>>
>> -- troy
>>
>>
>>
>> On Feb 12, 2009, at 9:11 AM, Wout Mertens wrote:
>>
>>> Ok,
>>>
>>> (no actual code yet, I don't have time to code right now :( )
>>>
>>> I have a project currently using an RDBMS and I'd like to port it  
>>> to CouchDB. One of the things I do is lock a table, choose a free  
>>> resource from a query on a static table and the session list,  
>>> assign the resource to a new session and unlock the table.
>>>
>>> How would I be able to do the same thing with CouchDB given that 2  
>>> sessions could start at the same time? I do have the advantage  
>>> that simultaneous starters would contact the same CouchDB instance.
>>>
>>> I was thinking of using sums: make a view that calculates the sum  
>>> of resources. A resource record would count as +1 and an in-use  
>>> record would be -1.
>>>
>>> Then when you reserve a resource, you save the in-use record.  
>>> After saving, look up the sum for the resource you reserved. If  
>>> it's not equal to 0, then use a stable algorithm to determine who  
>>> has to release the resource again.
>>>
>>> Would this close the race condition? Note that no documents are  
>>> overwritten at reservation time, each reservation doubles as the  
>>> event log. When the session clears up, the document that  
>>> represents it is updated to release the resource.
>>>
>>> Does this work? Is there a better way to do it?
>>>
>>> Thanks,
>>>
>>> Wout.
>
>