Return-Path: Delivered-To: apmail-jackrabbit-users-archive@minotaur.apache.org Received: (qmail 17817 invoked from network); 17 Feb 2010 14:35:43 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 17 Feb 2010 14:35:43 -0000 Received: (qmail 86265 invoked by uid 500); 17 Feb 2010 14:35:42 -0000 Delivered-To: apmail-jackrabbit-users-archive@jackrabbit.apache.org Received: (qmail 86204 invoked by uid 500); 17 Feb 2010 14:35:42 -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 86190 invoked by uid 99); 17 Feb 2010 14:35:42 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 17 Feb 2010 14:35:42 +0000 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 jukka.zitting@gmail.com designates 209.85.218.224 as permitted sender) Received: from [209.85.218.224] (HELO mail-bw0-f224.google.com) (209.85.218.224) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 17 Feb 2010 14:35:35 +0000 Received: by bwz24 with SMTP id 24so4234361bwz.9 for ; Wed, 17 Feb 2010 06:35:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :from:date:message-id:subject:to:content-type; bh=EVGE/48KzxebUerIng2T1H6lJSJQarqETGrqNuqFe/k=; b=AliBa8Io7CQ3ouzVfYjn/+FValfK/J7lve7ImxsYvt1xylD9hoWGNowxZIn8mNfR0E aSMoXNGdMaMrkdj2Um5YEOmzkrrlPbQV7CM9qS/8zYBm9SQjkHYYCXTxCuXfcaPncnXK I7MapDY1hY1RaPGe/watldG+vSYXTrjNV3aWI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; b=nXMNqjQKplC3KrqtR8NjvLAnbRZxtdoZ2U41vPlVhtmGtTHAhMeJdMRRngUbmMl76m 6jHA/Jl2RaTck5SNc1grhr3JffTTUe8/ihTtDvtV5JUcdK305seFaq8cWD6OpWfcC7/g rUu3wETJT/G4vf50/wVP+m9wp4esHumlSDhXo= MIME-Version: 1.0 Received: by 10.204.7.203 with SMTP id e11mr2352810bke.39.1266417313509; Wed, 17 Feb 2010 06:35:13 -0800 (PST) In-Reply-To: <562CB144-C0C1-47C1-B513-4FD6ED6B625C@tfd.co.uk> References: <3511F1D5-C133-4E7B-8816-83F054E58AE8@tfd.co.uk> <510143ac1002170243w7fcf6170n99844d56b4390cd3@mail.gmail.com> <562CB144-C0C1-47C1-B513-4FD6ED6B625C@tfd.co.uk> From: Jukka Zitting Date: Wed, 17 Feb 2010 15:34:53 +0100 Message-ID: <510143ac1002170634l4c8f263an640c14c09162ac45@mail.gmail.com> Subject: Re: Casandara and Jackrabbit To: users@jackrabbit.apache.org Content-Type: text/plain; charset=ISO-8859-1 Hi, On Wed, Feb 17, 2010 at 11:53 AM, Ian Boston wrote: > On 17 Feb 2010, at 10:43, Jukka Zitting wrote: >> I'm not aware of anything like that, though there's been some >> discussion about persistence on top of distributed databases or hash >> tables. The main problem with such approaches is the eventual >> consistency model that can be troublesome for the current Jackrabbit >> architecture. > > Is that because, in a cluster one JR node might get an event that an > Item exists, but its not yet present on the backend its connected to, > and there are no guarantees over the order in which items appear, > so, for instance, the hierarchy manager might find a child but not > the parent? Exactly. The current Jackrabbit architecture assumes that the underlying persistence store is always (not just eventually) consistent. > Do you have any pointers to the discussions so I can go and read ? It's been mostly coffee room discussions so far, but I'll bring up the topic soon on dev@ as a part of a larger Jackrabbit 3 roadmap discussion. BR, Jukka Zitting