From user-return-13540-apmail-couchdb-user-archive=couchdb.apache.org@couchdb.apache.org Sat Nov 06 17:42:22 2010 Return-Path: Delivered-To: apmail-couchdb-user-archive@www.apache.org Received: (qmail 76459 invoked from network); 6 Nov 2010 17:42:22 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 6 Nov 2010 17:42:22 -0000 Received: (qmail 62666 invoked by uid 500); 6 Nov 2010 17:42:52 -0000 Delivered-To: apmail-couchdb-user-archive@couchdb.apache.org Received: (qmail 62468 invoked by uid 500); 6 Nov 2010 17:42:52 -0000 Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@couchdb.apache.org Delivered-To: mailing list user@couchdb.apache.org Received: (qmail 62460 invoked by uid 99); 6 Nov 2010 17:42:52 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 06 Nov 2010 17:42:52 +0000 X-ASF-Spam-Status: No, hits=2.9 required=10.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_NONE,SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (nike.apache.org: local policy) Received: from [74.125.82.54] (HELO mail-ww0-f54.google.com) (74.125.82.54) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 06 Nov 2010 17:42:43 +0000 Received: by wwc33 with SMTP id 33so1007696wwc.23 for ; Sat, 06 Nov 2010 10:42:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.38.84 with SMTP id z62mr2505391wea.70.1289065341741; Sat, 06 Nov 2010 10:42:21 -0700 (PDT) Received: by 10.216.73.149 with HTTP; Sat, 6 Nov 2010 10:42:21 -0700 (PDT) Received: by 10.216.73.149 with HTTP; Sat, 6 Nov 2010 10:42:21 -0700 (PDT) In-Reply-To: References: Date: Sat, 6 Nov 2010 13:42:21 -0400 Message-ID: Subject: Re: Write race conditions, working without _rev From: Chad George To: user@couchdb.apache.org Content-Type: multipart/alternative; boundary=0016364c7bb1c97037049465e91a X-Virus-Checked: Checked by ClamAV on apache.org --0016364c7bb1c97037049465e91a Content-Type: text/plain; charset=ISO-8859-1 I think couchdb is more focused on documents which tend have few concurrent writes but possibly many concurrent reads. So never blocking a read is more important than never having an occasional write conflict. if you don't need to resolve conflicts...couchdb will always let one of them win...if there's a short time between the read and write then this should only effect nearly simultaneous updates. Alternately,to prevent having to read the doc just to get most recent rev maybe you could listen to the _changes feed to keep track of most recent rev for the docs with really high write freq On Nov 6, 2010 1:22 PM, "faust 1111" wrote: > I think update handlers don't help drop _rev dependency in all cases. > update handlers is not in-place update stuff. > if send two requests to one update handler together, you will catch > Conflict. > > > 2010/11/6 Michael > >> Very excellent. Thank you! >> >> >> On Fri, Nov 5, 2010 at 1:40 PM, Mark J. Reed wrote: >> > Look at update handlers. >> > >> > On Fri, Nov 5, 2010 at 12:44 PM, Michael wrote: >> >> On Fri, Nov 5, 2010 at 12:03 PM, Paul Davis < >> paul.joseph.davis@gmail.com> wrote: >> >>> >> >>> In the second case, the second person to write the document wins, >> >>> erasing any changes the first write's effects. The first writer will >> >>> then be in a state where his view of the database will be >> >>> inconsistent. The thing his, he can't know because without requiring a >> >>> _rev token he'll never get a notification of any sort of error. >> >> >> >> True, that is one workflow. I am not too concerned however about >> >> updates trampling each other each update does not care about previous >> >> revisions. This isn't people updating objects, but applications To be >> >> honest, I will catch the conflict and just ignore it because the data >> >> then is "new enough", however if I wanted the newest data, I would >> >> have to have: >> >> >> >> Read object to get rev >> >> Try save >> >> if resource conflict: >> >> read object for rev again >> >> try save >> >> if resource conflict: >> >> assume newer data and pass >> >> >> >> If that happens, I have 4 different hits to the database for nothing. >> >> On a multithreaded server, this would happen quite frequently. >> >> >> >> In my workflow, the ideal situation would be to write once, without a >> >> read, and for Couch to just accept the change in order. >> >> >> >> Is that possible? >> >> >> >> Thanks, >> >> >> >> Michael >> >> >> > >> > >> > >> > -- >> > Mark J. Reed >> > >> --0016364c7bb1c97037049465e91a--