jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ryan Dewell" <r...@dewell.org>
Subject Re: synchronous observation and caches
Date Sun, 17 Apr 2005 17:56:31 GMT
Hi David,

I guess I was looking at JCR as a purely client-side API.  Thus, I'm not 
concerned with what or where the repository that API is accessing, nor am I 
even concerned with all of the other possible clients accessing that 
repository, or what they are doing to it.  All I'm concerned with is me and 
my tiny world in the Session, at the client.  Thus, I want triggers as to 
what is happening in my Session only, not the repository as a whole.  Maybe 
this wouldn't be very useful to most, but in my experience has served alot 
of purposes in purely client-side uses (using Hibernate's event-like 
functionality).

I know that JCR is essentially baked, so perhaps it's something for a future 
JackRabbitt feature.   Does this type of client-side only, Session only 
notification seem useful to anyone else?  It seems to at least address 
Daniel's idea of a modification counter. Perhaps I'm not thinking big enough 
and there is a better way to implement this type of thing through some other 
abstraction (the previously discussed "decorator" idea sounds promising).

Ryan


"David Nuescheler" <david.nuescheler@gmail.com> wrote in message 
news:eb7e21905041708347b1e7cc3@mail.gmail.com...
[ 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
repository.
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?

regards,
david

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




Mime
View raw message