[ 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
