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.
