jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Nuescheler <david.nuesche...@gmail.com>
Subject synchronous observation and caches
Date Sun, 17 Apr 2005 15:34:05 GMT
[ Re: Getting "custom" objects from the repository? ]

hi ryan,

thanks for the question:

> On a semi-related noted, I've also been looking for similar functionality
> regarding properties that can be managed outside the realm of the Node.  The
> observation listeners seem like the perfect place for updating things like
> "last modified" or a "modication counter" integer.  Unfortunately, they can
> only "observe" and don't seem well-suited to actually modifying the node.
> It would be nice for the aforementioned uses if a listener could actually
> "intercept" a Node before it was persisted and make changes to it.  I guess
> this would be similar to what is possible in a relaional trigger.
> Unless, there is a way to centrally manage properties like "last modified"
> or a "modification counter" in JCR that I'm missing?

first of all, i very much share the idea that in a repository both
synchronous triggers and asynchronous observations have 
very relevant usecases.

there are two answers to this question, (a) with respect to the jsr-170 spec
and (b) with respect to the jackrabbit implementation.

(a) in the jsr-170 spec (aka jcr):
synchronous observation (essentially triggers) has been 
removed from v1.0 the specification since the requirement would 
be very hard to accomplish in particular for any non-java-based 
this particularly refers all the legacy repositories that have 
big install basis and are very unflexible when it comes to 
changes in their core architecture. 
for those repository it is very questionable to communicate 
inside their transactional context to some (possibly 
remote) jvm and execute "java-triggers".

(b) in the jackrabbit implementation:
as ryan pointed out, the observation listeners seem like
a very intuitive place to also deal with events synchronously
(possibly vetoable). so jackrabbit offers a very similar 
interface to deal with synchronous observations.
jackrabbit uses this facility internally for operations
such as the update of the search index.

however (with respect to the earlier question of daniel):
jackrabbit can be used both in a client/server
architecture (model 3 [1]) or in an "in-proc" 
(model 1&2 [1]) fashion.
i would argue that cache invalidation triggered by
synchronous observation makes little sense in 
both cases.

1) client/server
synchronous observation in a client/server setup 
would be a huge resource drain, since it has to 
transmit information over the network during
the commit of a transaction.

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.

any thoughts?


[1] http://incubator.apache.org/jackrabbit/arch/deploy.html

View raw message