From jackrabbit-dev-return-1514-apmail-incubator-jackrabbit-dev-archive=www.apache.org@incubator.apache.org Sat Apr 02 17:21:26 2005 Return-Path: Delivered-To: apmail-incubator-jackrabbit-dev-archive@www.apache.org Received: (qmail 99088 invoked from network); 2 Apr 2005 17:21:26 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 2 Apr 2005 17:21:26 -0000 Received: (qmail 87268 invoked by uid 500); 2 Apr 2005 17:21:26 -0000 Mailing-List: contact jackrabbit-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: jackrabbit-dev@incubator.apache.org Delivered-To: mailing list jackrabbit-dev@incubator.apache.org Received: (qmail 87255 invoked by uid 99); 2 Apr 2005 17:21:26 -0000 X-ASF-Spam-Status: No, hits=0.4 required=10.0 tests=DNS_FROM_RFC_ABUSE,RCVD_BY_IP,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (hermes.apache.org: domain of stefan.guggisberg@gmail.com designates 64.233.170.205 as permitted sender) Received: from rproxy.gmail.com (HELO rproxy.gmail.com) (64.233.170.205) by apache.org (qpsmtpd/0.28) with ESMTP; Sat, 02 Apr 2005 09:21:25 -0800 Received: by rproxy.gmail.com with SMTP id c16so1055016rne for ; Sat, 02 Apr 2005 09:21:23 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=CeYeo8AwG4LdPmQOyi3v3KmUsDnVNQHTyeoR68X8D0NDKEVlE/9pz6SqbYshroTVe25jvEW6L5VG5B1CvHZLk2Wg5pllyI5hZ2UXdTcsqgSHSIEqIqgMLhn1vtgXIn70TzquClkLUomhIrIy1kxhsT6VmU1AvWfSk/gP0AK9rm0= Received: by 10.38.67.50 with SMTP id p50mr3855481rna; Sat, 02 Apr 2005 09:21:22 -0800 (PST) Received: by 10.38.152.61 with HTTP; Sat, 2 Apr 2005 09:21:22 -0800 (PST) Message-ID: <90a8d1c0050402092150595077@mail.gmail.com> Date: Sat, 2 Apr 2005 19:21:22 +0200 From: Stefan Guggisberg Reply-To: Stefan Guggisberg To: jackrabbit-dev@incubator.apache.org Subject: Re: cluster and cache question In-Reply-To: <424D75AC.2040806@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit References: <424D75AC.2040806@gmail.com> X-Virus-Checked: Checked X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N hi edgar On Apr 1, 2005 6:24 PM, Edgar Poce wrote: > Hi > > I'm trying to use jackrabbit in a cluster scenario. Since jdbc calls are > rather expensive caching results is a common practice, but as you all > pointed PMs are not designed to be smart. So, do you think caching > should be in the PM?, it should be somewhere else?, it shouldn't be at > all? any more option? ItemState instances are cached on multiple layers. Please have a look at dominique's earlier post which IMO explains jackrabbit's design quite nicely: http://thread.gmane.org/gmane.comp.apache.jackrabbit.devel/1172 the SharedItemStateManager is at the bottom layer and caches ItemState instances read from the PM. this memory-sensitive cache, apart from helping to reduce PM calls, guarantees that there's only *one* ItemState instance for any given id on this layer. this is crucial for jackrabbit's support of isolation levels. caching in the PM would therefore IMO be redundant if not disadvantageous because it would use up (memory) resources that could be used more efficiently by jackrabbit. regarding clustering: clustering is a very interesting topic and we had quite a few discussions on how it could be supported in jackrabbit. clustering can IMO not be entirely delegated to the PM. it has to be tackled on a higher level. the sticking point is how to synchronize the multiple jackrabbit instances in a cluster. there's no easy answer to that and it would certainly require considerable work in jackrabbit's core. as our main priority is getting jackrabbit version 1.0 out clustering support has to wait i'm afraid. cheers stefan > > I'm thinking of a cluster scenario with > jdbc PM + distributed cache + jackrabbit > instead of > any PM + jackrabbit + rmi server + rmi client > > I prefer the first config because there are products that build the > cache on each server and don't pass the cached objects around the cluster. > > It seems I often feel tempted to bad practices :(, so I'd like to know > your opinion before taking a decision. > > thanks in advance > edgar >