From dev-return-2899-apmail-couchdb-dev-archive=couchdb.apache.org@couchdb.apache.org Tue Feb 24 16:03:53 2009 Return-Path: Delivered-To: apmail-couchdb-dev-archive@www.apache.org Received: (qmail 98868 invoked from network); 24 Feb 2009 16:03:53 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 24 Feb 2009 16:03:53 -0000 Received: (qmail 84942 invoked by uid 500); 24 Feb 2009 16:03:53 -0000 Delivered-To: apmail-couchdb-dev-archive@couchdb.apache.org Received: (qmail 84594 invoked by uid 500); 24 Feb 2009 16:03:52 -0000 Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@couchdb.apache.org Delivered-To: mailing list dev@couchdb.apache.org Received: (qmail 84583 invoked by uid 99); 24 Feb 2009 16:03:52 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 24 Feb 2009 08:03:52 -0800 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of zachary.zolton@gmail.com designates 74.125.44.28 as permitted sender) Received: from [74.125.44.28] (HELO yx-out-2324.google.com) (74.125.44.28) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 24 Feb 2009 16:03:42 +0000 Received: by yx-out-2324.google.com with SMTP id 31so872801yxl.5 for ; Tue, 24 Feb 2009 08:03:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=NtW2uF+Xi0Ui3TnaD1q0gUg/AXwbbMyT5118gPDIOVI=; b=Xb4EuspUAQ7pW/rqEzgY9pb+oyIlFfUJLWO8U3IRKKvECDldrKMk5JxsjYXsvw+gjG M7/f755yROmCucg8TBE75vU/VByU1D98WvMyGG29ghKgV+seTuVcSrndD5hLvwZNbcH5 560k8eZ8gHU7E3XiVgPcued5mz5Seq5d53f/Y= 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=xYeCe8NHEy5Teg8wd2A4864C2k/+ijaouqfiuU0jsi50MxZoSUveFYBhq2L+g9w+Ns +dWhl3B7s2M73fEMp/euhTQoCW/kyklmHgLbk7t+ZT/isKSarFvojTs7bYa3FXYR/iU8 SRtWQkWpn4gd0K1J5pzn0LWKwXog8UE9aXTAg= MIME-Version: 1.0 Received: by 10.101.1.11 with SMTP id d11mr5906222ani.113.1235491401131; Tue, 24 Feb 2009 08:03:21 -0800 (PST) In-Reply-To: <5AC3C09C-E980-40AD-8ADE-B5E3C620A01A@apache.org> References: <5AC3C09C-E980-40AD-8ADE-B5E3C620A01A@apache.org> Date: Tue, 24 Feb 2009 10:03:21 -0600 Message-ID: Subject: Re: ACID vs BASE From: Zachary Zolton To: dev@couchdb.apache.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org Thanks for the reply! It looks like they go into the more advanced Bayou consistency, and Byzantine failure modes, but I don't think I'll need to cover that soon... But a more important question: If I have two couch servers: A and B And, I want to load-balance users between them, would it be the responsibility of the web/app servers to ensure that a user session "sticks" to either A or B, after performing a write/update? At least until the data has had a chance to replicate between servers...? (I'm guessing this is what all the "monotonic updates discussion is about...?) On Tue, Feb 24, 2009 at 9:54 AM, Jan Lehnardt wrote: > > On 24 Feb 2009, at 16:49, Zachary Zolton wrote: > >> As a developer (without an advanced degree :^P) trying to understand >> Eventual Consistency, I happened upon these slides: >> >> http://www.cs.berkeley.edu/~istoica/classes/cs268/06/notes/20-BFTx2.pdf >> >> I know consistency models are a hot topic around here, so I thought >> I'd ask if this would make a good introductory text for me to explain >> the techniques to some colleagues of mine. Or does anyone take >> theoretical issue with it contents? > > I skimmed the contents and it looks cool to me for an introduction. > > Cheers > Jan > -- > >