I see in the source code there is a notification thread in the ObservationManagerFactory.
about event notification; I think that all the clients should receive those notifications. In the case of a local repository it is obvious it works. In the case of a proxy
like JCR RMI, it depends how it is coded but it could be possible to have it but that would need to have the client to export a remote object to have callbacks
(or use any other similar mechanism). I don't know if the implementation currently do it.
Daniel Dekany wrote:
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.
-- Julien Viet JBoss Portal Lead Developer
