hi daniel, > 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. using the JCR api there is no way to get access to synchronous events. i think the spec is clear about that. so you will know that "your object mapper is not working correctly" to put it in your words ;)
of course every repository is free to add more descriptor keys, however this does not say anthing about the api used to acquire synchronous events. > 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"). i strongly disagree, and i see that you interpret "... has sufficient access rights" completely the wrong way. "it doesn't mater who has modified the node, if it has modified..." that is absolutely true, but the statement in the spec refers to the fact that the session that registers must have read access to an item to receive information about its modification, which of course makes sense. for your "cache system" that should not be an issue though. > 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. it seems like you are on to something ;) if i am reading your comments, i think you are looking for a distributed (client) "cache-system", that is transactionally invalidated without any network overhead (neither pull nor push) (and apparently implements the full complexity of non-descript access control on the client side??) ? is that somehow correct? if yes, please let me know any concrete design suggestions (maybe even code?) for the above, i would be extremely interested. regards, david
