Return-Path: Delivered-To: apmail-jackrabbit-dev-archive@www.apache.org Received: (qmail 30980 invoked from network); 8 Feb 2008 17:03:09 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 8 Feb 2008 17:03:09 -0000 Received: (qmail 41515 invoked by uid 500); 8 Feb 2008 17:03:00 -0000 Delivered-To: apmail-jackrabbit-dev-archive@jackrabbit.apache.org Received: (qmail 41483 invoked by uid 500); 8 Feb 2008 17:03:00 -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 41473 invoked by uid 99); 8 Feb 2008 17:03:00 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 08 Feb 2008 09:03:00 -0800 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 marcel.reutegger@gmx.net designates 213.165.64.20 as permitted sender) Received: from [213.165.64.20] (HELO mail.gmx.net) (213.165.64.20) by apache.org (qpsmtpd/0.29) with SMTP; Fri, 08 Feb 2008 17:02:30 +0000 Received: (qmail invoked by alias); 08 Feb 2008 17:02:32 -0000 Received: from l2tp.day.com (EHLO [192.168.10.18]) [62.192.10.243] by mail.gmx.net (mp011) with SMTP; 08 Feb 2008 18:02:32 +0100 X-Authenticated: #894343 X-Provags-ID: V01U2FsdGVkX1+7nNJ8J+u7/FMtmk2p5VY3vnVD0ABjLFqKA681Av lhzoYVW5VyVTJM Message-ID: <47AC8B26.5050308@gmx.net> Date: Fri, 08 Feb 2008 18:02:30 +0100 From: Marcel Reutegger User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: dev@jackrabbit.apache.org Subject: Re: SPI caching, was: [jira] Resolved: (JCR-1361) Lock test assumes that changes in one session are immediately visible in different session References: <10340167.1202296988432.JavaMail.jira@brutus> <47A9A975.70701@gmx.de> <47A9D3EE.5000108@day.com> <47A9D69B.60806@gmx.de> <47AABD1C.5020500@gmx.net> <47AAE7B4.4070803@gmx.de> <47AAFD83.1090001@gmx.net> <47AB02BD.20500@gmx.de> <47AB1A68.5040404@gmx.net> <47AC4DEB.2060900@gmx.net> <47AC54B5.3070101@gmx.de> <47AC5A9E.8060305@gmx.net> <47AC5ED0.6080708@gmx.de> <47AC81A5.4050309@gmx.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Virus-Checked: Checked by ClamAV on apache.org David Rauschenbach wrote: > also worth mentioning is why a requested-depth argument is missing from > getItemInfos. It's just a little strange for the server to choose what to do, > or to have a pre-configured nodetype-specific batch strategy configured > there, when the client is where it's at, where it's known what's to be > requested. our primary SPI client that we have in mind is jcr2spi. here we are in the same tight spot. jcr2spi does not know in advance what properties a client will request after it got a node. even if we had the ability in the SPI to pass a hint, jcr2spi cannot make use of it in a reasonable way. for jcr2spi there are only two patterns it can distinguish. a JCR client gets a named item (getNode/Property()) or an iterator over items (getNodes/Properties()). At least the latter should not result in individual calls for each item. regards marcel