couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benoit Chesneau <bchesn...@gmail.com>
Subject Re: Write race conditions, working without _rev
Date Sun, 07 Nov 2010 07:15:23 GMT
On Fri, Nov 5, 2010 at 5: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
>

 Just use one document per transaction. Then a view to retrieve the
last one 'more recent in your case?).

- benoît

Mime
View raw message