jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ben Pickering <benpicker...@gmail.com>
Subject Re: synchronous observation and caches
Date Sun, 17 Apr 2005 17:29:35 GMT
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 <ddekany@freemail.hu> wrote:
> Sunday, April 17, 2005, 5:34:05 PM, David Nuescheler wrote:
> > [ 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]
> 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.
> 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.
> --
> Best regards,
>  Daniel Dekany


View raw message