Return-Path: Delivered-To: apmail-geronimo-dev-archive@www.apache.org Received: (qmail 65190 invoked from network); 13 Jan 2006 10:54:21 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 13 Jan 2006 10:54:21 -0000 Received: (qmail 85644 invoked by uid 500); 13 Jan 2006 10:54:10 -0000 Delivered-To: apmail-geronimo-dev-archive@geronimo.apache.org Received: (qmail 85589 invoked by uid 500); 13 Jan 2006 10:54:09 -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 85569 invoked by uid 99); 13 Jan 2006 10:54:09 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 13 Jan 2006 02:54:09 -0800 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received-SPF: neutral (asf.osuosl.org: local policy) Received: from [209.235.255.182] (HELO jetty3.inetu.net) (209.235.255.182) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 13 Jan 2006 02:54:07 -0800 Received: (qmail 96674 invoked from network); 13 Jan 2006 10:53:45 -0000 Received: from host86-137-55-203.range86-137.btcentralplus.com (HELO ?192.168.0.4?) (jules@86.137.55.203) by jetty3.inetu.net with AES256-SHA encrypted SMTP; 13 Jan 2006 10:53:45 -0000 Message-ID: <43C78686.2010207@coredevelopers.net> Date: Fri, 13 Jan 2006 10:52:54 +0000 From: Jules Gosnell User-Agent: Mozilla Thunderbird 1.0.7-1.1.fc4 (X11/20050929) X-Accept-Language: en-us, en MIME-Version: 1.0 To: wadi-dev@incubator.apache.org CC: dev@geronimo.apache.org Subject: Re: Replication using totem protocol References: <59575.68.101.239.161.1136400404.squirrel@68.101.239.161> <01CD8D63-412D-4B7C-B7C9-C77228829439@iq80.com> <43C6BF40.4010006@apache.org> <59483.68.101.239.161.1137099644.squirrel@68.101.239.161> <43C6DDF6.8010202@apache.org> <43C6E016.5060505@toolazydogs.com> <60567.68.101.239.161.1137109674.squirrel@68.101.239.161> <43C6EBD7.7050408@apache.org> <61095.68.101.239.161.1137111975.squirrel@68.101.239.161> <43C6F444.6090004@apache.org> <62319.68.101.239.161.1137117523.squirrel@68.101.239.161> In-Reply-To: <62319.68.101.239.161.1137117523.squirrel@68.101.239.161> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N lichtner@bway.net wrote: >>lichtner@bway.net wrote: >> >> >>>Well, you guys let me know if I can help you in any way. >>> >>> >>Keep on talking ;-) >> >> > >Okay. I will ask you a question then. What are you doing as far caching >entity beans? > > In terms or replication or some form of distributed invalidation, I'm not aware that this has been discussed yet. This is another one for the forthcoming doc - briefly : If you cluster an entity bean on two nodes naively, you lose many of the benefits of caching. This is because neither node, at the beginning of a transaction, knows whether the other node has changed the beans contents since it was last loaded into cache, so the cache must be assumed invalid. Thus, you find yourself going to the db much more frequently than you would like, and the number of trips increases linearly with the number of clients - i.e. you are no longer scalable. If you can arrange for the cache on one node to notify the cache on other nodes, whenever an entity is changed, then the other caches can optimise their actions, so that rather assuming that all beans are invalid, they can pinpoint the ones that actually are invalid and only reload those. You could go one step further and send, not an invalidation, but a replication message. This would contain the Entity's new value and head off any reloading from the DB at all.... All of this needs to be properly integrated with e.g. transactions, locking etc... Perhaps Totem might be useful here ? Jules -- "Open Source is a self-assembling organism. You dangle a piece of string into a super-saturated solution and a whole operating-system crystallises out around it." /********************************** * Jules Gosnell * Partner * Core Developers Network (Europe) * * www.coredevelopers.net * * Open Source Training & Support. **********************************/