From: Robert Klemme Date: 2011-05-20T22:56:12+09:00 Subject: Re: Another Couch potato question: Dealing with classic concurrency conflict On Fri, May 20, 2011 at 3:11 PM, Oren Shani wrote: > Robert K. wrote in post #999847: >> On Fri, May 20, 2011 at 12:50 PM, Oren Shani >> wrote: >>> Apache boast that CouchDB does not lock the DB documents as SQL locks >>> tables, and that users always get their requests granted via a queue. >> >> First of all, SQL does not lock tables.  SQL is a declarative language >> which describes relations.  There are various RDBMS around which use >> variants of SQL.  SQL itself has no knowledge of locking.  Locking is >> something which happens in a RDBMS to ensure certain transactional >> properties.  This also depends on the concurrency level chosen at a >> time. >> >> For example, in the default concurrency level PostgreSQL and Oracle do >> not block readers if an update is under way (called MVCC).  Readers >> simply see an older version of the record - which seems to be similar >> to what CouchDB does: >> http://couchdb.apache.org/docs/overview.html > > I know that... well... you understand what I meant :-) Yes, but others might not. I thought the clarification would help. :-) >>> But what about the classic concurrency conflicts that SQL uses locks for >>> in the first place? for example, suppose I have a field in some document >>> that each client should read, increase by some value and then save, as >>> you probably know, if two clients read the field and then both save it, >>> only the addition done by one of them will be actually saved. >> >> Not sure about that.  Could be that two versions shortly after each >> other are saved which means that practically nobody sees the first >> version of the two.  See the link above. >> >>> So I wonder what is the best practice for handling this kind of >>> situations with Couch Potato or with CouchDB at all? I really don't want >>> to have to use SQL just because of that... >> >> Generally this is best discussed in a CouchDB forum, I'd say. :-)  In >> the worst case you need to manually lock.  I doubt though that CouchDB >> is intended for such a use case.  It may be the wrong tool for the job >> if you need to ensure exclusive access to a resource such a shared >> counter. > Apache have a CouchDB mailing list, not a forum. I hate mailing lists > but I will > post a question there too (one must be willing to suffer for a noble > cause). :-) > Still I thought maybe someone here could give me a more > Ruby-oriented advice :-) Well, if all your clients are Ruby programs you could of course implement the locking in Ruby e.g. by having a lock server process which is talked to via DRb. All the tools you need for that are there: DRb for communication, Mutex and Monitor for locking. Whether that's a good solution is a different cup of tea to answer. :-) It's always a bit difficult to talk about these things on such a general level... Kind regards robert -- remember.guy do |as, often| as.you_can - without end http://blog.rubybestpractices.com/