jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Dekany <ddek...@freemail.hu>
Subject Re: Getting "custom" objects from the repository?
Date Sun, 17 Apr 2005 17:59:40 GMT
Sunday, April 17, 2005, 6:19:27 PM, David Nuescheler wrote:

> 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
>> 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.

Well I don't really wanted synchronous events, it was just somebody said
that the observation feature should solve my problem with those
out-of-sync caches, and then I have pointed out that the spec. talks
about synchronous events so that will not work...

>> 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.

Ops... yeah, I have misinterpreted the API docs. Sorry.

> for your "cache system" that should not be an issue 
> though.

Yes, that shouldn't be... other things like async. events do. Anyway,
I'm not sticking to implement cache synchronization with observers at

>> 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 ;)

Yeah, and I think I'm not alone: I want to store stuff in the content
repository that is "serious", like XML documents, page templates,
scripts, etc, etc, etc. "Whoa! What does this guy thinking? Such an
extreme idea!" :) I think it's a fairly common usage of a content
repository, or not? You see, if I want to store some data of employees
like their name, address, phone-number, then fine, I can store it with 3
string properties of a myapp:employee node, and I can even access that
directly as jcr.Properties in may application code, no problem. But if I
store articles as XDocBook documents (XML) in the repository (isn't that
something that should work?), I have to store the XML as a string
property in the repository. And, my Java code (that should transform the
XML to a Web page or something) definitely can't do anything with that
flat string that I get from JCR, so I must add a layer over JCR that
transform that to a org.w3c.dom.Document. Isn't it something obvious?
Because it turns out that however I want to add that layer, it's not
possible with JCR... well, unless whenever someone visits the Web page
with that article, I get that supposedly long string (the XML) from the
repository, and then translate it to a Document object. Every and each
time the article is visited! Because, I can't implement that layer in a
way so it caches without breaking fundamental things like, I don't know,
transaction boundaries, atomicity of changes, etc. So, come on guys, do
everybody think that I must be an alien from another galaxy :), or it is
a damn down-to-earth everyday thing what I'm talking about?

> 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? 

*Somehow* yes, except that I want something much simpler, much primitive
(because may standards are looow.. because I'm around for too long, so I
just want to achieve an acceptable level). Like, I don't count queering
*something* (like some kind of time stamp) from the repository again and
again as an overhead (but see above, I hope it's clear what I want). Or,
I don't want to change the Java objects... if I want to change them, I
will just write the JCR repository directly, and then it should be
ensured that nobody will get the now outdated cached object in a new
transaction after I have committed the transaction where the
modification was made.

> if yes, please let me know any concrete design 
> suggestions (maybe even code?) for the above, i 
> would be extremely interested.
> regards,
> david

Best regards,
 Daniel Dekany

View raw message