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: refresh method or version stamp
Date Sun, 17 Apr 2005 23:59:05 GMT
> User modifies template X and template Y in the repository, and then he
> commits the transaction. So, looking at it from outside that
> transaction, the modification of the two templates has happened in the
> same atomic moment, right? Thus, after the transaction was committed, I
> never want visitors to see that X is in its old state, and Y is its new
> state. Because either both is in its new state, or both is it in old
> state. Right? Now, if I have a cache between JCR and the CMS that is
> updates with whatever unpredictable ways, then it can happen that the
> cache will serve the object made for the old X, while it serve the
> object made for the new Y. And this is phenomenon that I really want to
> avoid.

sure, no problem. since all the observation events 
of a transaction are batched together and are transported 
in a bundle of obervation events, they arrive precisely at the
same time at the observation listener.

... but now you started to make me really curious, how do 
you get your in-memory cache to be transactional in the 
first place? are all the getter-method on your mycms.template 
(java-)synchronized on your overall template cache class?

anyhow let's say while responding to the http-request you 
access the template X from your template cache twice with 
commit in between, how should the application behave? 
once old and once new, within the same http-response??

or let's say you have a web-page with two pictures, 
both rendered by template Y... you see where i 
am going... i think this whole discussion is absolutely 

> Another example... I have updated template X (committed the
> transaction). Then I go and visit the page that uses that template. And
> I don't want to see the old template, because the cache updates itself
> with 10 seconds of delay and like. This is another phenomenon that I
> want to avoid.
10 seconds? our cache is observation based not time based.
in real-life we are talking milliseconds.

> Is it free from the two phenomena I have described above?
sure, easily.

> If yes, I'm all ears to hear how did you implemented it, since basically
> that's what I'm asking here from the beginning.
see above.

> >> In fact I have asked
> >> for a solution originally, with the optimistic assumption
> >> that the Expert Group who has developed JCR has considered
> >> this obvious use-case.
> > we used those exact use-cases to try to argue to
> > keep synchronous observation it in the spec.
> > maybe i was not clear before, the synchronous observation
> > has been removed from the spec (it was completely speced
> > out in the beginning) because of variety of unresolved
> > technical questions for existing non-java repository
> > vendors.
> OK for me. But what did you (the expert group) say about the whole
> higher level use-case, that is: the repository client wants to cache
> those objects that are too expensive to be re-created every time a
> repository "query" was executed. (Do you understand the use-case I'm
> referring to?)

i don't know what you mean by "query". the term query has a very 
specific meaning in jsr-170, and you seem to be using it for 
something different.

if you talk about cache invalidation, personally i think in almost any 
case the async observation provided in jcr is absolutely sufficient.
keep in mind, we talk milliseconds and all the events of a transaction
are a batched up.


View raw message