On Fri, Feb 13, 2009 at 5:59 AM, Wout Mertens <[email protected]> wrote: > Oh wow, I completely missed that functionality :-) > > Actually, I think you mean that I should rewrite the resource documents, > since they are being locked. Let's look at the sequence: > > CouchDB: C > App instances: A and B > Resource: R_0 (rev 0 unused), R_1_A (rev 1, resource reserved by A), R_1_B > (rev 1, resource reserved by B) > > Time 0: > A reads R_0 from C > B reads R_0 from C > > Time 1: > A writes R_1_A to C > B writes R_1_B to C > > Time 2: > A gets failure from C => A knows it didn't reserve R > B gets success from C => B has the resource reserved > > Is that correct? Man that's easy :) > > Can I count on this always being true for a single-node CouchDB? > What about a replicating CouchDB cloud where competing instances (A and B) > connect to the same CouchDB? > > 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? > > Wout. >
I think the traditional method would be to nominate a write node for each document a la consistent hashing or some other scheme. Then no matter where you read a document from, you're guaranteed to have conflict resolution at write time, Also, remember, that people don't expect perfection like software engineers. If once a year, I go to book a conference room, and a few minutes later I get an email that says, "ooops, scheduling conflict, can you reschedule?" I wouldn't care so much. As long as it can be fixed quickly and easily, no one much minds assuming its a low frequency event. Granted, that whole argument is invalid for things like the email thread. :) HTH, Paul Davis > 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. > >
