Return-Path: Delivered-To: apmail-jackrabbit-dev-archive@www.apache.org Received: (qmail 82724 invoked from network); 3 May 2006 13:48:25 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 3 May 2006 13:48:25 -0000 Received: (qmail 67962 invoked by uid 500); 3 May 2006 13:48:10 -0000 Delivered-To: apmail-jackrabbit-dev-archive@jackrabbit.apache.org Received: (qmail 67765 invoked by uid 500); 3 May 2006 13:48:09 -0000 Mailing-List: contact dev-help@jackrabbit.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@jackrabbit.apache.org Delivered-To: mailing list dev@jackrabbit.apache.org Received: (qmail 67756 invoked by uid 99); 3 May 2006 13:48:09 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 03 May 2006 06:48:09 -0700 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received-SPF: pass (asf.osuosl.org: local policy) Received: from [62.192.67.250] (HELO alpha.eurodyn.com) (62.192.67.250) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 03 May 2006 06:48:08 -0700 Received: from parnitha.eurodyn.com (parnitha.eurodyn.com [10.251.0.3]) by alpha.eurodyn.com (8.12.9/8.12.9) with ESMTP id k43Dlh9r006442 for ; Wed, 3 May 2006 16:47:43 +0300 (EET DST) Received: by parnitha.eurodyn.com with ESMTP id QAA16799; Wed, 3 May 2006 16:47:43 +0300 (EET DST) Received: from [10.254.253.182] (HELO gkaradimitr) by eurodyn.com (CommuniGate Pro SMTP 4.0.5) with ESMTP id 4316408; Wed, 03 May 2006 16:47:43 +0300 From: "Giota Karadimitriou" To: Subject: RE: jackrabbit & clustering Date: Wed, 3 May 2006 16:48:20 +0300 Message-ID: <005a01c66eb8$3d291c20$b6fdfe0a@gkaradimitr> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 In-Reply-To: <4458AE2B.1080306@gmx.net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 Importance: Normal X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N Thanks for your time and comments once more Marcel, another idea would be that maybe I could send the item states from the shared item state manager of one node to the shared item state managers of other nodes and validate their cache using the public available methods "stateCreated/stateDiscarded/stateModified". The question is whether this would suffice (sharing and revalidating the state items among shareditemstatemanagers)or more things are needed to ensure integrity. regards Giota > -----Original Message----- > From: Marcel Reutegger [mailto:marcel.reutegger@gmx.net] > Sent: Wednesday, May 03, 2006 4:21 PM > To: dev@jackrabbit.apache.org > Subject: Re: jackrabbit & clustering > > Giota Karadimitriou wrote: > > Thanks for the answers Marcel. One extra question: since shared item > > state manager is entirely responsible for controlling integrity; is > > there a way to check (by querying somehow the database) whether an item > > state is up to date and if not to just reload it from the database. > > Couldn't this ideally work for cluster since everything in our > > application is being saved in a common database? (Of course performance > > would go down with all these db calls but cache would become valid) > > well, in theory you could retrieve the item state again from the > persistence manager and compare the modification count with the item > state that you already have. if it is the same you know its up-to-date. > but that may change at any given point in time. imo you need some sort > of distributed locking to be sure that you only work on up-to-date item > states. > > regards > marcel