jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Nuescheler <david.nuesche...@gmail.com>
Subject Re: Getting "custom" objects from the repository?
Date Sun, 17 Apr 2005 16:19:27 GMT
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

Mime
View raw message