Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@couchdb.apache.org
Received-SPF: pass (nike.apache.org: domain of randall.leeds@gmail.com
 designates 209.85.161.52 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type:content-transfer-encoding;
        b=vRpObshg9QlKXDqkdUzddEgk99tSGGqrkYBUKv4KSbpzlEWQ00eJk3nqAggennWyX4
         bGm8Hs6OygLMaY/TjCm/SmdjysijZxzN+wnFKxT9olzDHNZRh/DSERan3M1eMnzZbJJ1
         rLyrH/SJ0KG4c2S9Ujl9Wnf5hHBmSvcWDrLnE=
MIME-Version: 1.0
In-Reply-To: <AANLkTinkHhHoHijvc4+GOWyOpNmcRb151iPUDrjKBBoo@mail.gmail.com>
References: <AANLkTinkHhHoHijvc4+GOWyOpNmcRb151iPUDrjKBBoo@mail.gmail.com>
Date: Tue, 30 Nov 2010 16:24:49 -0500
Message-ID: <AANLkTim-5LJmJ+_Z=FwN6JDPsJ=NoeOFQau17yrH_u9Y@mail.gmail.com>
Subject: Re: avoiding races with concurrent invocations on different couchdb
 instances... was: CouchDB hosting services and same-domain origin
From: Randall Leeds <randall.leeds@gmail.com>
To: user@couchdb.apache.org
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Sad to see you never got a response to this. It's been sitting starred
in my inbox for a while.

On Fri, Nov 12, 2010 at 05:17, Mike Fedyk <mfedyk@mikefedyk.com> wrote:
> On Fri, Nov 5, 2010 at 12:50 PM, Gabriel Farrell <g@grrawr.com> wrote:
>> If you're wondering how to do this for a CouchApp, you might look at
>> the setup Mikeal talks about (NodeJS behind CouchDB) at
>> http://jsconf.eu/2010/speaker/nodejs_couchdb_crazy_delicious.html
>> (especially at around 12:15).
>>
>
> Does he or anyone go into more detail on methods for coordinating
> action evocation based on replication (ie, _changes)? =C2=A0I don't like
> the idea of one app hanging off one instance of couchdb. =C2=A0then you
> still have to implement failover detection, etc. =C2=A0if it starts with
> all nodes being active, but maybe the first one starts once it's new,
> and the second hits if it's 5 minutes old, etc. or I was thinking of a
> distributed queue but in order to take an item off the queue, you have
> to "take ownership" of it, and get acks from N other couch instances
> to make sure you're not racing with them...
>
> Has anyone thought of this type of stuff and elaborated on it?
>

I've thought about it only little, but your idea of "taking ownership"
seems sound, but it's hard to imagine immediately how it'd actually
work. It's easy to update a document to say "I'm the owner" and if
that replicates cleanly such that you see it on N couches you should
be assured that you've taken that item. If there are conflicts, Couch
will take care of making sure all replicas choose the same version, so
the same process should work. You should try it out by hanging on the
_changes feed of 3 couches and set them all replicating continuously.
See if you can "claim" documents by updating an "owner" field or
something. Let us know how it goes!