Return-Path: Delivered-To: apmail-jackrabbit-users-archive@locus.apache.org Received: (qmail 9104 invoked from network); 2 Aug 2007 13:26:28 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 2 Aug 2007 13:26:28 -0000 Received: (qmail 27567 invoked by uid 500); 2 Aug 2007 13:26:26 -0000 Delivered-To: apmail-jackrabbit-users-archive@jackrabbit.apache.org Received: (qmail 27544 invoked by uid 500); 2 Aug 2007 13:26:26 -0000 Mailing-List: contact users-help@jackrabbit.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: users@jackrabbit.apache.org Delivered-To: mailing list users@jackrabbit.apache.org Received: (qmail 27535 invoked by uid 99); 2 Aug 2007 13:26:26 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 02 Aug 2007 06:26:26 -0700 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of alessandro.bologna@gmail.com designates 209.85.132.240 as permitted sender) Received: from [209.85.132.240] (HELO an-out-0708.google.com) (209.85.132.240) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 02 Aug 2007 13:26:22 +0000 Received: by an-out-0708.google.com with SMTP id c37so99561anc for ; Thu, 02 Aug 2007 06:26:01 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:mime-version:in-reply-to:references:content-type:message-id:content-transfer-encoding:from:subject:date:to:x-mailer; b=ur5oqNB9CqF08SRFeNHMKb8xHCPi+iqxYPrWGtv42rRYKJ2q1fKoANs1Qx96Byj1PKu+UlaZVzYsitPpp6JAJuBJ7SqgkUf3jvyRUPBhx4ursDggRxvyrsl1lF4011KCppreRo8yGfweHXIG3SM5QEoURbHbvzTQPev1+PF8OUk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:mime-version:in-reply-to:references:content-type:message-id:content-transfer-encoding:from:subject:date:to:x-mailer; b=DWEgyOtSVKgE4ywSAeVr/gr2Y0XEJR2GSE8QuG0fS5Ut40Qu9q+QfZxg7bqmgVXl5iUQjsXRt8CAyyny1mT5+HI6FTQq1QhrFD2dPk/oBnejfe+W/26498Ed6Arm2Wqc8NnzPBBUSW84eUYa8ueyOodkpLZqXB5DhibQNBEkpqM= Received: by 10.100.44.13 with SMTP id r13mr1064206anr.1186061161589; Thu, 02 Aug 2007 06:26:01 -0700 (PDT) Received: from ?192.168.128.101? ( [74.66.251.221]) by mx.google.com with ESMTPS id d34sm2409281and.2007.08.02.06.26.00 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 02 Aug 2007 06:26:00 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: <46B1D9C1.5000200@planet.nl> References: <46B1D51B.8040708@planet.nl> <90a8d1c00708020615u17eb6b7aic9fd06d86349bf24@mail.gmail.com> <46B1D9C1.5000200@planet.nl> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <8A1789ED-7D14-412D-B0C1-26686CB46B9E@gmail.com> Content-Transfer-Encoding: 7bit From: Alessandro Bologna Subject: Re: Clearing WorkspaceInfo ItemStateManager Date: Thu, 2 Aug 2007 09:25:54 -0400 To: users@jackrabbit.apache.org X-Mailer: Apple Mail (2.752.3) X-Virus-Checked: Checked by ClamAV on apache.org Actually clustering works because multiple repositories *are* writing to the same database. When one repository writes into it, the others are notified via the journal, and pick up the changes from the database and index them in their local indexes. Alessandro On Aug 2, 2007, at 9:18 AM, Nick Stolwijk wrote: > I have considered clustering, but I thought it would go horrible > wrong. If multiple repositories in a cluster starts writing to the > same database, I guess bad things happen. > > To clearify, multiple applications starts their own repository with > the same database behind it. If you write to one of the > repositories, it gets written into the database. If you cluster the > repositories, the other repositories also wants to write to the > same database. > > I could be wrong, but I guess that would go wrong. :) > > With regards, > > Nick Stolwijk > > Stefan Guggisberg wrote: >> On 8/2/07, Nick Stolwijk wrote: >> >>> I've got a problem with multiple repositories that are reading >>> from one >>> database. This was going well, because there was no writing to the >>> repositories (so read only data). Now, one of the repositories is >>> going >>> to write to the database. Because of the ItemStateManager inside >>> Jackrabbit, the other repositories aren't picking this up. Is >>> there some >>> way, to get to the WorkspaceInfo or ItemStateManager instance to >>> clear >>> it once in a while? >>> >>> With regards, >>> >>> Nick Stolwijk >>> >>> Ps. I know this is a not supported way of doing it. But for now, we >>> can't get the customer to run a stand alone repository, that all >>> applications can connect to. >>> >>> >> >> have you considered using jackrabbit's clustering feature? >> >> cheers >> stefan >> >> >