Another Couch potato question: Dealing with classic concurrencyconflict

[Oren Shani]

Hi All,

So now (with some starter help I got here), I played around with Couch
Potato enough to see that I really like it. I have one big problem
though and this is really critical for what I am developing.

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

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

Many thanks,

Oren

 

[Robert Klemme]

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

 

[Oren Shani]

Robert K. wrote in post #999847:

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

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.


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

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

Thanks

Oren

 

[Robert Klemme]

Robert K. wrote in post #999847:

I know that... well... you understand what I meant

Yes, but others might not. I thought the clarification would help.

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

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

 

[Oren Shani]

Robert K. wrote in post #999871:

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.

Hmmm... well I thought about that, and kind of hoped not to have to use
a lock server, but if I will have no other choice then using DRb is a
good idea, thanks!

It's always a bit difficult to talk about these things on such a general
level...

This is true. Hopefully, I will soon be able to share with the forum
what I am doing and then I will be able to be more specific