jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Dekany <ddek...@freemail.hu>
Subject Re: synchronous observation and caches
Date Sun, 17 Apr 2005 16:40:50 GMT
Sunday, April 17, 2005, 5:34:05 PM, David Nuescheler wrote:

> [ Re: Getting "custom" objects from the repository? ]
> 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.

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