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" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] [ 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
