Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!aioe.org!feeder.news-service.com!de-l.enfer-du-nord.net!feeder2.enfer-du-nord.net!feeder1.enfer-du-nord.net!talisker.lacave.net!lacave.net!not-for-mail From: Oren Shani Newsgroups: comp.lang.ruby Subject: Another Couch potato question: Dealing with classic concurrency conflict Date: Fri, 20 May 2011 05:50:13 -0500 Organization: Service de news de lacave.net Lines: 25 Message-ID: NNTP-Posting-Host: bristol.highgroove.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Trace: talisker.lacave.net 1305888639 54115 65.111.164.187 (20 May 2011 10:50:39 GMT) X-Complaints-To: abuse@lacave.net NNTP-Posting-Date: Fri, 20 May 2011 10:50:39 +0000 (UTC) X-Received-From: This message has been automatically forwarded from the ruby-talk mailing list by a gateway at comp.lang.ruby. If it is SPAM, it did not originate at comp.lang.ruby. Please report the original sender, and not us. Thanks! For more details about this gateway, please visit: http://blog.grayproductions.net/categories/the_gateway X-Mail-Count: 383512 X-Ml-Name: ruby-talk X-Rubymirror: Yes X-Ruby-Talk: Xref: x330-a1.tempe.blueboxinc.net comp.lang.ruby:4807 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/.