couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael <newmani...@gmail.com>
Subject Re: Write race conditions, working without _rev
Date Fri, 05 Nov 2010 19:23:31 GMT
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
View raw message