incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From faust 1111 <faust...@gmail.com>
Subject Re: Write race conditions, working without _rev
Date Sat, 06 Nov 2010 17:21:47 GMT
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