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

Groups > comp.lang.ruby > #4810

Re: Another Couch potato question: Dealing with classic concurrency conflict

Show all headers | View raw

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

Back to comp.lang.ruby | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

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

csiph-web