From jackrabbit-dev-return-1775-apmail-incubator-jackrabbit-dev-archive=www.apache.org@incubator.apache.org Sun Apr 17 17:29:45 2005 Return-Path: Delivered-To: apmail-incubator-jackrabbit-dev-archive@www.apache.org Received: (qmail 51284 invoked from network); 17 Apr 2005 17:29:45 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 17 Apr 2005 17:29:45 -0000 Received: (qmail 81074 invoked by uid 500); 17 Apr 2005 17:29:38 -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 81047 invoked by uid 99); 17 Apr 2005 17:29:38 -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 benpickering@gmail.com designates 64.233.184.198 as permitted sender) Received: from wproxy.gmail.com (HELO wproxy.gmail.com) (64.233.184.198) by apache.org (qpsmtpd/0.28) with ESMTP; Sun, 17 Apr 2005 10:29:37 -0700 Received: by wproxy.gmail.com with SMTP id 69so1082516wri for ; Sun, 17 Apr 2005 10:29:35 -0700 (PDT) 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:content-disposition:references; b=jts9wg91Q6zF5GsLoy9mCMnWrbU8EE2pLGOBU/QMqmC3q0eDceQqfYjsGRW9VpDqQGmuf8TQJSR3WaAuJA+apBOCuYv6iUvpACNx9udtU/eWTChDaEMqwP/Gg/nIXoaX+PNNJFvt/iqaVcv6trxz1ea6o6GxBY86vcPPNgstyLU= Received: by 10.54.54.60 with SMTP id c60mr1603050wra; Sun, 17 Apr 2005 10:29:35 -0700 (PDT) Received: by 10.54.21.4 with HTTP; Sun, 17 Apr 2005 10:29:35 -0700 (PDT) Message-ID: Date: Sun, 17 Apr 2005 18:29:35 +0100 From: Ben Pickering Reply-To: Ben Pickering To: jackrabbit-dev@incubator.apache.org, Daniel Dekany Subject: Re: synchronous observation and caches In-Reply-To: <1098296015.20050417184050@freemail.hu> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <181174235.20050416061620@freemail.hu> <426119F3.4060809@jboss.com> <826865421.20050416205632@freemail.hu> <42618509.4030200@gmail.com> <71217167.20050417014140@freemail.hu> <1098296015.20050417184050@freemail.hu> X-Virus-Checked: Checked X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N There have been two aspects to this discussion that I don't want to get confused: 1. Providing higher-level APIs (such as User, Workflow etc) that are based on JCR data items 2. Providing a performant implementation of such APIs with bi-directional updates/notifications in a client-server scenario Now (2) is obviously an outstanding problem even in the JDBC realm -- not sure there's much we can do there. The contribution I made to "Getting "custom" objects from the repository?" was really about (1), and whether there's any particular approach preferred by the design of the JCR API and might be taken as a pattern others might follow. This would open the possibility of being able to download and slot in pre-written APIs for User, Workflow, Image, XML and so forth. (On the implementation side, I'd be perfectly happy to bake a version number into the objects I create based on repository data, give the objects a commit() method and have them throw if I try to commit them after a concurrent change. This is how I've done it in the past with databases; I'm perfectly happy to send messages to the user to say 'your data has changed in the meantime' -- but I work in the web, where that kind of thing doesn't cause users' heads to explode. Most of the time :) On 4/17/05, Daniel Dekany wrote: > Sunday, April 17, 2005, 5:34:05 PM, David Nuescheler wrote: >=20 > > [ Re: Getting "custom" objects from the repository? ] > [snip] > > 2) in-proc same jvm > > in memory caching for performance reason is > > proabably almost pointless to begin with since > > jackrabbit caches in memory already. > > there may be certain applications that have > > requirements on reading content that go > > beyond what jackrabbit can deliver, but i > > would argue that a content repository like > > jackrabbit (opposed to relational databases) > > already provides highly efficient > > in-memory caching of nodes and properties > > for read operations. > [snip] >=20 > Just to prevent misunderstandings: the cache I have talked about is not > the cache of the nodes and raw property values (String-s, Booleans, > etc.). It's a cache that stores Java objects made based on the nodes > (property values) queried from the repository. Like, a mycms:script node > should be "translated" to a mycms.Script object (that stores the > pre-processed ready-for-execution script), and the that mycms.Script > object had to be cached for later reuse, until the mycms:script node in > question is not modified in the repository. >=20 > Now, for the cache to work correctly, it's not required that the cache > is notified immediately about the modification of the node. It's not > even required that it is notified at all (I mean, with a message > triggered by the modification of the node). It's enough if when the node > is needed next time, it will turn out that the node was modified since > it was last "translated" to the mycms.Script object (which is stored in > the cache), so the cached object must be thrown and re-created from the > new vales stored in the node. For better memory utilization (*not* for > the correct operation) it is desirable that the cache receives a such > notifications (so it doesn't store an outdated object for long time, > just to drop it when with the next query it turns out that it was > outdated), but that need not be synchronous. >=20 > -- > Best regards, > Daniel Dekany >=20 >=20 --=20 Cheers, Ben