On 08/03/2009, at 11:43 AM, Chris Anderson wrote:
On Sat, Mar 7, 2009 at 5:00 PM, Antony Blakey
<antony.bla...@gmail.com> wrote:
On 08/03/2009, at 11:14 AM, Damien Katz wrote:
The problem is if there is a network error, a client has no way to
if a
POST commit was successful. The success or failure response can
get lost,
and the id of the document is completely unknown to the client.
This is a different problem than the double post - would the same
problem
not occur if the client failed? e.g. if there's no way of finding the
resultant document, then the failure modes seem symmetric.
Client failure has to be expected. A POST is fire-and-forget. If you
use it right (as we strive to) you can even make it seem idempotent.
Tighter coupling between the client and server is the last thing we
need.
Sure, but my point was that specific problem of creating a document
and having the POST response fail to arrive (and hence be lost to the
client), is equivalent to (and IMO much less likely than) the client
failing. I'm not suggesting that Couch should deal with this case, and
consequently I don't think it should deal with the POST response
failing to arrive. At the moment I don't see how this has any
relationship to the problem of duplicate posts.
Maybe a generic solution could
be to allow a client supplied UUID in the request, which is
retained in the
server for some short time (in network terms) to make POSTs
generically
idempotent over some window?
Setting up window agreement is not the sort of problem I think CouchDB
should strive to solve. It may be that CouchDB is well suited to it,
but I think the proper point of implementation is at the application
level. CouchDB aims to be a sort of lowest-common denominator. If you
implement is as a CouchApp that emits JSON and maintains server
closures in JavaScript, you'd pretty much have what you need, and it'd
be replicateable across raw CouchDB nodes.
I don't see how this would solve the problem of e.g. double
invocations of a replicate/compact/purge POST. I'm not sure what kind
of delays between double POSTs one needs to deal with, but given that
POSTs (and maybe all methods) do have this problem (regardless of
whether the error is in the browser stack or middleware), this would
seem to be a generic solution that cannot be solved in the client.
Antony Blakey
-------------
CTO, Linkuistics Pty Ltd
Ph: 0438 840 787
Some defeats are instalments to victory.
-- Jacob Riis
