Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.ruby > #4807 > unrolled thread

Another Couch potato question: Dealing with classic concurrency conflict

Back to article view | Back to comp.lang.ruby

Contents

  Another Couch potato question: Dealing with classic concurrency conflict Oren Shani <orenshani7@gmail.com> - 2011-05-20 05:50 -0500
    Re: Another Couch potato question: Dealing with classic concurrency conflict Robert Klemme <shortcutter@googlemail.com> - 2011-05-20 07:05 -0500
      Re: Another Couch potato question: Dealing with classic concurrency conflict Oren Shani <orenshani7@gmail.com> - 2011-05-20 08:11 -0500
        Re: Another Couch potato question: Dealing with classic concurrency conflict Robert Klemme <shortcutter@googlemail.com> - 2011-05-20 08:56 -0500
          Re: Another Couch potato question: Dealing with classic concurrency conflict Oren Shani <orenshani7@gmail.com> - 2011-05-20 09:28 -0500

#4807 — Another Couch potato question: Dealing with classic concurrency conflict

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

-- 
Posted via http://www.ruby-forum.com/.

[toc] | [next] | [standalone]

#4808

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/

[toc] | [prev] | [next] | [standalone]

#4810

Robert K. wrote in post #999847:
> 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
>

I know that... well... you understand what I meant :-)

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

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

-- 
Posted via http://www.ruby-forum.com/.

[toc] | [prev] | [next] | [standalone]

#4814

On Fri, May 20, 2011 at 3:11 PM, Oren Shani <orenshani7@gmail.com> wrote:
> Robert K. wrote in post #999847:
>> 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
>
> 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/

[toc] | [prev] | [next] | [standalone]

#4817

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 :-)
>
> Kind regards
>
> robert

-- 
Posted via http://www.ruby-forum.com/.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.ruby

csiph-web