Saturday, April 16, 2005, 10:39:30 PM, Julien Viet wrote: > ok for 1/ but 2/, isnt the notification synchronous ? (even if the spec > does not mandate it).
The specification says: This specification defines only asynchronous event delivery. It is possible for a repository to also implement synchronous events in order to support the vetoing of changes before they happen. However, this functionality is outside the scope of this specification. As it is "outside the scope of the specification", you don't even have Repositiry.OPTION_SYNCHRONOUS_OBSERVATION_SUPPORTED or something like that, so the object mapper can't check if it can work correctly over the JCR implementation in use or not. Then, from the API docs of javax.jcr.observation.EventListener: An EventListener can be registered via the ObservationManager object. Event listeners are notified asynchronously, and see events after they occur and the transaction is committed. An event listener only sees events for which the session that registered it has sufficient access rights. which is absolutely not encouraging. Especially note that last sentence. Because, it doesn't mater who has modified the node, if it has modified, the cache system must realize that it is out of sync, so it never serves outdated objects (that would ruing the "ACID"). Then, I'm not 100% sure about this one, but I think event listeners are running inside the repository server, and not inside the repository client. And since the cache is (typically) in the client's JVM, the event listeners had connect back to the client's JVM somehow to send the notifications... lot of complication and point of failure. And if the event notification is synchronous, then it possibly causes serious performance degradation, since then the commitment of the transaction is done only if the event listener has completed the notification of the cache system. -- Best regards, Daniel Dekany
