Return-Path: Delivered-To: apmail-geronimo-dev-archive@www.apache.org Received: (qmail 89924 invoked from network); 2 Feb 2006 12:41:53 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 2 Feb 2006 12:41:53 -0000 Received: (qmail 55226 invoked by uid 500); 2 Feb 2006 12:41:49 -0000 Delivered-To: apmail-geronimo-dev-archive@geronimo.apache.org Received: (qmail 55156 invoked by uid 500); 2 Feb 2006 12:41:48 -0000 Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: List-Post: Reply-To: dev@geronimo.apache.org List-Id: Delivered-To: mailing list dev@geronimo.apache.org Received: (qmail 55139 invoked by uid 99); 2 Feb 2006 12:41:48 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 02 Feb 2006 04:41:48 -0800 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (asf.osuosl.org: domain of andyp@bea.com designates 63.96.162.5 as permitted sender) Received: from [63.96.162.5] (HELO ussjmh01.bea.com) (63.96.162.5) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 02 Feb 2006 04:41:47 -0800 Received: from eagle.bea.com ([172.24.28.57]) by ussjmh01.bea.com (Switch-3.0.5/Switch-3.0.0) with ESMTP id k12CfOro020554; Thu, 2 Feb 2006 04:41:25 -0800 Message-Id: <6.2.5.6.2.20060202123257.02709900@bea.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 02 Feb 2006 12:41:28 +0000 To: dev@geronimo.apache.org From: Andy Piper Subject: Re: Replication using totem protocol Cc: wadi-dev@incubator.apache.org, dev@geronimo.apache.org, dev@wadi.codehaus.org In-Reply-To: <43CE09A6.2010108@coredevelopers.net> References: <59575.68.101.239.161.1136400404.squirrel@68.101.239.161> <01CD8D63-412D-4B7C-B7C9-C77228829439@iq80.com> <58577.68.101.239.161.1137097683.squirrel@68.101.239.161> <60263.68.101.239.161.1137109409.squirrel@68.101.239.161> <0A4CB6D2-AE7F-43E5-9A7C-D463F67E1FA0@iq80.com> <43CB94D4.9000904@coredevelopers.net> <43CC2744.8050105@coredevelopers.net> <43CC362B.3080900@coredevelopers.net> <43CCADAB.5020707@coredevelopers.net> <43CE09A6.2010108@coredevelopers.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-PMX-Version: 4.7.0.111621, Antispam-Engine: 2.0.2.0, Antispam-Data: 2006.02.02.034605 X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N At 09:25 AM 1/18/2006, Jules Gosnell wrote: >I haven't been able to convince myself to take the quorum approach because... > >shared-something approach: >- the shared something is a Single Point of Failure (SPoF) - >although you could use an HA something. That's how WAS and WLS do it. Use an HA database, SAN or dual-ported scsi. The latter is cheap. The former are probably already available to customers if they really care about availability. >- If the node holding the lock 'goes crazy', but does not die, the >rest of the This is generally why you use leases. Then your craziness is only believed for a fixed amount of time. >cluster becomes a fragment - so it becomes an SPoF as well. >- used in isolation, it does not take into account that the lock may >be held by the smallest cluster fragment You generally solve this again with leases. i.e. a lock that is valid for some period. >shared-nothing approach: Nice in theory but tricky to implement well. Consensus works well here. >- I prefer this approach, but, as you have stated, if the two halves >are equally sized... >- What if there are two concurrent fractures (does this happen?) >- ActiveCluster notifies you of one membership change at a time - so >you would have to decide on an algorithm for 'chunking' node loss, >so that you could decide when a fragmentation had occurred... If you really want to do this reliably you have to assume that AC will send you bogus notifications. Ideally you want to achieve a consensus on membership to avoid this. It sounds like totem solves some of these issues. andy