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