couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chad George <c...@mgproducts.com>
Subject Re: Write race conditions, working without _rev
Date Sat, 06 Nov 2010 17:42:21 GMT
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" <faust451@gmail.com> 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 <newmaniese@gmail.com>
>
>> Very excellent. Thank you!
>>
>>
>> On Fri, Nov 5, 2010 at 1:40 PM, Mark J. Reed <markjreed@gmail.com> wrote:
>> > Look at update handlers.
>> >
>> > On Fri, Nov 5, 2010 at 12:44 PM, Michael <newmaniese@gmail.com> 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 <markjreed@gmail.com>
>> >
>>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message