You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@couchdb.apache.org by Michael <ne...@gmail.com> on 2010/11/05 16:57:30 UTC
Write race conditions, working without _rev
Hello everyone;
Thanks again for all the help that I have gotten with Couch, this
group has really been helpful for my learning process.
I have gotten so far in my application that I am starting to find some
problems. The biggest one I have found is actually pertaining to
adding a _rev to every save. I read the existing object and pull the
_rev from that. This however creates a race condition where an
object's _rev might be out of date while I save.
In reality, I would love to write without a read--save a little
overhead-- but everything I have read and tried says that this will
produce an error. How do I get around this sort of race condition?
Even better, is there a way to update an object with reading first.
The second part is also a question in this article
http://perfcap.blogspot.com/2010/10/comparing-nosql-availability-models.html
from Adrian Cockcroft (part 2 of question 4).
Thanks for the help again,
Michael
Re: Write race conditions, working without _rev
Posted by Chad George <ch...@mgproducts.com>.
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" <fa...@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 <ne...@gmail.com>
>
>> Very excellent. Thank you!
>>
>>
>> On Fri, Nov 5, 2010 at 1:40 PM, Mark J. Reed <ma...@gmail.com> wrote:
>> > Look at update handlers.
>> >
>> > On Fri, Nov 5, 2010 at 12:44 PM, Michael <ne...@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 <ma...@gmail.com>
>> >
>>
Re: Write race conditions, working without _rev
Posted by faust 1111 <fa...@gmail.com>.
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 <ne...@gmail.com>
> Very excellent. Thank you!
>
>
> On Fri, Nov 5, 2010 at 1:40 PM, Mark J. Reed <ma...@gmail.com> wrote:
> > Look at update handlers.
> >
> > On Fri, Nov 5, 2010 at 12:44 PM, Michael <ne...@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 <ma...@gmail.com>
> >
>
Re: Write race conditions, working without _rev
Posted by Michael <ne...@gmail.com>.
Very excellent. Thank you!
On Fri, Nov 5, 2010 at 1:40 PM, Mark J. Reed <ma...@gmail.com> wrote:
> Look at update handlers.
>
> On Fri, Nov 5, 2010 at 12:44 PM, Michael <ne...@gmail.com> wrote:
>> On Fri, Nov 5, 2010 at 12:03 PM, Paul Davis <pa...@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 <ma...@gmail.com>
>
Re: Write race conditions, working without _rev
Posted by "Mark J. Reed" <ma...@gmail.com>.
Look at update handlers.
On Fri, Nov 5, 2010 at 12:44 PM, Michael <ne...@gmail.com> wrote:
> On Fri, Nov 5, 2010 at 12:03 PM, Paul Davis <pa...@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 <ma...@gmail.com>
Re: Write race conditions, working without _rev
Posted by Ido Ran <id...@gmail.com>.
Hi,
I think this question raise the general question of "document model" (in the
same way OO programming has Object Model) and that is "how do you model you
document to contain you problem domain including the process of changing
those documents".
In relation databases we use table diagram and description of transactions
to describe it I think we need tools (not has to be software, pen and papare
are great too) to describe out document oriented database.
The question of should you have one document that get updated or several
documents which relate using other means is a good question.
Ido
On Sun, Nov 7, 2010 at 9:15 AM, Benoit Chesneau <bc...@gmail.com> wrote:
> On Fri, Nov 5, 2010 at 5:44 PM, Michael <ne...@gmail.com> wrote:
> > On Fri, Nov 5, 2010 at 12:03 PM, Paul Davis <pa...@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
>
Re: Write race conditions, working without _rev
Posted by Benoit Chesneau <bc...@gmail.com>.
On Fri, Nov 5, 2010 at 5:44 PM, Michael <ne...@gmail.com> wrote:
> On Fri, Nov 5, 2010 at 12:03 PM, Paul Davis <pa...@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
Re: Write race conditions, working without _rev
Posted by Michael <ne...@gmail.com>.
On Fri, Nov 5, 2010 at 12:03 PM, Paul Davis <pa...@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
Re: Write race conditions, working without _rev
Posted by couchdb user <co...@gmail.com>.
On Mon, Nov 8, 2010 at 10:17 AM, Johannes Schneider
<ma...@cedarsoft.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> For me this looks different:
>
> curl --HEAD http://127.0.0.1:5984/example/post98
> HTTP/1.1 200 OK
> Server: CouchDB/1.0.1 (Erlang OTP/R13B)
> Etag: "1-8908180fecd9b17657889f91973f89eb"
> Date: Mon, 08 Nov 2010 15:16:14 GMT
> Content-Type: text/plain;charset=utf-8
> Content-Length: 122
> Cache-Control: must-revalidate
>
>
> So the rev seems to be the Etag...
>
Yes, I typed the wrong parameters, the rev is the etag
>
> On 11/07/2010 03:25 AM, couchdb user wrote:
>> To follow up on what Chad said about avoiding reading the doc to get
>> the _rev, you can also use a HEAD request, while it is an extra
>> request, it will use a lot less resources.
>>
>>
>> $ curl -HEAD http://127.0.0.1:5984/example/post98
>> {"_id":"post98","_rev":"1-9e6543bfb3cbf3b7c36904a1ea4b806f","tags":"[2,5]"}
>>
>> Regards,
>>
>>
>> On Sat, Nov 6, 2010 at 3:52 PM, Luciano Ramalho <lu...@ramalho.org> wrote:
>>> On Fri, Nov 5, 2010 at 2:03 PM, Paul Davis <pa...@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.
>>>
>>> As I understand, the situation you describe above never happens in
>>> practice with CouchDB. A second PUT to the same document _id will
>>> always require the _rev attribute, so there's no way to overwrite a
>>> previous update by accident. This is one of the best features of
>>> CouchDB for document-oriented persistency.
>>>
>>>
>>> --
>>> Luciano Ramalho
>>> programador repentista || stand-up programmer
>>> Twitter: @luciano
>>>
>
> - --
> Johannes Schneider - blog.cedarsoft.com
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
>
> iQEcBAEBAgAGBQJM2BSJAAoJEAytD9R7Qv6d0nIH/ROBieDaYqnOoniF6ekaZWtt
> tM7P/HQsnCssTLpqnB+a57lyeCz02pK6kOmRbNTk9qt6nJSr7KvGQf8ktRljkpZS
> uzqTzhaFNvhHLPdEkQn1ZwNMuLlaF9xP7e6teTiPvD+dFPS8oOj4NeaQvb5uyGJl
> dMlcQqATdUrTl1MX0KoWLdzEj0uyxXAow9FuXCdHPE7u9LcMvTOcyFdbCa/pTNdI
> 4qu2Annk88lylihZces+Q4q25DI4hfv1Phncuej605QgaWwY6Uezb5JjDi76jW7B
> XfscTq4RKNRxpLuQBYwL7LGJSSQg7ebyQBNquLQcl5niNoqgkt1ldbfZIt7eik4=
> =XiX3
> -----END PGP SIGNATURE-----
>
Re: Write race conditions, working without _rev
Posted by Johannes Schneider <ma...@cedarsoft.com>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
For me this looks different:
curl --HEAD http://127.0.0.1:5984/example/post98
HTTP/1.1 200 OK
Server: CouchDB/1.0.1 (Erlang OTP/R13B)
Etag: "1-8908180fecd9b17657889f91973f89eb"
Date: Mon, 08 Nov 2010 15:16:14 GMT
Content-Type: text/plain;charset=utf-8
Content-Length: 122
Cache-Control: must-revalidate
So the rev seems to be the Etag...
On 11/07/2010 03:25 AM, couchdb user wrote:
> To follow up on what Chad said about avoiding reading the doc to get
> the _rev, you can also use a HEAD request, while it is an extra
> request, it will use a lot less resources.
>
>
> $ curl -HEAD http://127.0.0.1:5984/example/post98
> {"_id":"post98","_rev":"1-9e6543bfb3cbf3b7c36904a1ea4b806f","tags":"[2,5]"}
>
> Regards,
>
>
> On Sat, Nov 6, 2010 at 3:52 PM, Luciano Ramalho <lu...@ramalho.org> wrote:
>> On Fri, Nov 5, 2010 at 2:03 PM, Paul Davis <pa...@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.
>>
>> As I understand, the situation you describe above never happens in
>> practice with CouchDB. A second PUT to the same document _id will
>> always require the _rev attribute, so there's no way to overwrite a
>> previous update by accident. This is one of the best features of
>> CouchDB for document-oriented persistency.
>>
>>
>> --
>> Luciano Ramalho
>> programador repentista || stand-up programmer
>> Twitter: @luciano
>>
- --
Johannes Schneider - blog.cedarsoft.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
iQEcBAEBAgAGBQJM2BSJAAoJEAytD9R7Qv6d0nIH/ROBieDaYqnOoniF6ekaZWtt
tM7P/HQsnCssTLpqnB+a57lyeCz02pK6kOmRbNTk9qt6nJSr7KvGQf8ktRljkpZS
uzqTzhaFNvhHLPdEkQn1ZwNMuLlaF9xP7e6teTiPvD+dFPS8oOj4NeaQvb5uyGJl
dMlcQqATdUrTl1MX0KoWLdzEj0uyxXAow9FuXCdHPE7u9LcMvTOcyFdbCa/pTNdI
4qu2Annk88lylihZces+Q4q25DI4hfv1Phncuej605QgaWwY6Uezb5JjDi76jW7B
XfscTq4RKNRxpLuQBYwL7LGJSSQg7ebyQBNquLQcl5niNoqgkt1ldbfZIt7eik4=
=XiX3
-----END PGP SIGNATURE-----
Re: Write race conditions, working without _rev
Posted by Randall Leeds <ra...@gmail.com>.
The only resource saved is the network.
If this is optimized it could potentially provide great benefit from
an etag caching proxy, but at this time CouchDB handles both the same
way, save for not sending the body on HEAD.
-Randall
On Sat, Nov 6, 2010 at 19:25, couchdb user <co...@gmail.com> wrote:
> To follow up on what Chad said about avoiding reading the doc to get
> the _rev, you can also use a HEAD request, while it is an extra
> request, it will use a lot less resources.
>
>
> $ curl -HEAD http://127.0.0.1:5984/example/post98
> {"_id":"post98","_rev":"1-9e6543bfb3cbf3b7c36904a1ea4b806f","tags":"[2,5]"}
>
> Regards,
>
>
> On Sat, Nov 6, 2010 at 3:52 PM, Luciano Ramalho <lu...@ramalho.org> wrote:
>> On Fri, Nov 5, 2010 at 2:03 PM, Paul Davis <pa...@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.
>>
>> As I understand, the situation you describe above never happens in
>> practice with CouchDB. A second PUT to the same document _id will
>> always require the _rev attribute, so there's no way to overwrite a
>> previous update by accident. This is one of the best features of
>> CouchDB for document-oriented persistency.
>>
>>
>> --
>> Luciano Ramalho
>> programador repentista || stand-up programmer
>> Twitter: @luciano
>>
>
RE: Write race conditions, working without _rev
Posted by Nils Breunese <N....@vpro.nl>.
I don't know about your curl, but mine only understands --head or -I if you want to do a HEAD request.
Nils.
________________________________________
Van: couchdb user [couchdbuser@gmail.com]
Verzonden: zondag 7 november 2010 3:25
Aan: user@couchdb.apache.org
Onderwerp: Re: Write race conditions, working without _rev
To follow up on what Chad said about avoiding reading the doc to get
the _rev, you can also use a HEAD request, while it is an extra
request, it will use a lot less resources.
$ curl -HEAD http://127.0.0.1:5984/example/post98
{"_id":"post98","_rev":"1-9e6543bfb3cbf3b7c36904a1ea4b806f","tags":"[2,5]"}
------------------------------------------------------------------------
VPRO
phone: +31(0)356712911
e-mail: info@vpro.nl
web: www.vpro.nl
------------------------------------------------------------------------
Re: Write race conditions, working without _rev
Posted by couchdb user <co...@gmail.com>.
To follow up on what Chad said about avoiding reading the doc to get
the _rev, you can also use a HEAD request, while it is an extra
request, it will use a lot less resources.
$ curl -HEAD http://127.0.0.1:5984/example/post98
{"_id":"post98","_rev":"1-9e6543bfb3cbf3b7c36904a1ea4b806f","tags":"[2,5]"}
Regards,
On Sat, Nov 6, 2010 at 3:52 PM, Luciano Ramalho <lu...@ramalho.org> wrote:
> On Fri, Nov 5, 2010 at 2:03 PM, Paul Davis <pa...@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.
>
> As I understand, the situation you describe above never happens in
> practice with CouchDB. A second PUT to the same document _id will
> always require the _rev attribute, so there's no way to overwrite a
> previous update by accident. This is one of the best features of
> CouchDB for document-oriented persistency.
>
>
> --
> Luciano Ramalho
> programador repentista || stand-up programmer
> Twitter: @luciano
>
Re: Write race conditions, working without _rev
Posted by Luciano Ramalho <lu...@ramalho.org>.
On Fri, Nov 5, 2010 at 2:03 PM, Paul Davis <pa...@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.
As I understand, the situation you describe above never happens in
practice with CouchDB. A second PUT to the same document _id will
always require the _rev attribute, so there's no way to overwrite a
previous update by accident. This is one of the best features of
CouchDB for document-oriented persistency.
--
Luciano Ramalho
programador repentista || stand-up programmer
Twitter: @luciano
Re: Write race conditions, working without _rev
Posted by Paul Davis <pa...@gmail.com>.
On Fri, Nov 5, 2010 at 11:57 AM, Michael <ne...@gmail.com> wrote:
> Hello everyone;
>
> Thanks again for all the help that I have gotten with Couch, this
> group has really been helpful for my learning process.
>
> I have gotten so far in my application that I am starting to find some
> problems. The biggest one I have found is actually pertaining to
> adding a _rev to every save. I read the existing object and pull the
> _rev from that. This however creates a race condition where an
> object's _rev might be out of date while I save.
>
> In reality, I would love to write without a read--save a little
> overhead-- but everything I have read and tried says that this will
> produce an error. How do I get around this sort of race condition?
> Even better, is there a way to update an object with reading first.
>
> The second part is also a question in this article
> http://perfcap.blogspot.com/2010/10/comparing-nosql-availability-models.html
> from Adrian Cockcroft (part 2 of question 4).
>
> Thanks for the help again,
>
> Michael
>
I'm confused about your concern a bout a race condition when requiring
_rev to be specified. Not specifying a _rev doesn't prevent a race
condition, it just prevents you from knowing whether you just trampled
an update.
For instance, in the case where a _rev is required and two people
attempt to write simultaneously, one person will get a conflict error.
The person receiving the error will then know that they have to look
at the current value and figure out how to resolve the conflict.
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.
HTH,
Paul Davis