couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Anderson <>
Subject Re: Tail Append Headers
Date Fri, 22 May 2009 21:35:52 GMT
On Fri, May 22, 2009 at 2:22 PM, Brian Candler <> wrote:
> On Fri, May 22, 2009 at 01:46:54PM -0700, Chris Anderson wrote:
>> > Exactly. It'd be a "trivial" change to the batch=ok feature to add
>> > wait=true so that the client hangs open on the connection and receives
>> > a 201 Created when the batch is committed. It'd actually be sort of a
>> > challenging patch, but I can perhaps add it before 1.0.
>> >
>> > I've added it to Jira here:
>> Forgot to mention that you can almost get this now by using batch=ok
>> and then when the client wants to be sure that the batch is committed,
>> send a POST to /db/_ensure_full_commit
>> You'll have a little more http overhead this way but the semantics are
>> mostly the same.
> Hmm. So what are the semantics? Are you saying that _ensure_full_commit
> doesn't actually cause a commit, but waits until the next commit takes
> place? (What if the commit had already taken place?)

batch=ok with wait=true will return 201 Created with the same
guarantees as a normal PUT, but using a RAM buffer to smooth index

You can approximate the behavior by using batch=ok and sending
_ensure_full_commit periodically. If CouchDB has crashed you can act
like the docs saved since the last _ensure_full_commit are potentially
lost. For bonus points, track the db start time to avoid missing quick


> Also: what exactly is the difference with or without batch=ok? Does batch=ok
> mean that the doc sits in CouchDB's RAM buffer, and without it, it gets
> written out to the kernel's VFS buffer (also in RAM)? In that case, I can't
> really see why they would be any different from the client's point of view.
> But I've probably misunderstood.
> Regards,
> Brian.

Chris Anderson

View raw message