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