From: Robert Klemme <shortcutter@...>
Date: 2011-05-20T21:05:53+09:00
Subject: Re: Another Couch potato question: Dealing with classic concurrency conflict

On Fri, May 20, 2011 at 12:50 PM, Oren Shani <orenshani7@gmail.com> 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

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

Cheers

robert

-- 
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/