jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Dekany <ddek...@freemail.hu>
Subject Re: refresh method or version stamp
Date Mon, 18 Apr 2005 12:59:20 GMT
Yeah, I know told I have stopped, but just one more... I promise it will
be useful... :)

Monday, April 18, 2005, 11:23:03 AM, David Nuescheler wrote:

> hi daniel,
>
>> "... better don't run a nuclear reactor with this object mapping layer though."
>
> yes, ... please don't. ;) LOL

Just put it clearly: the solution you are using does *not* prevent those
transient phenomenons, so it ruin the idea of transactions, it doesn't
obey transaction boundaries (that it is acceptable in your exact
use-case is a different question).
<example-if-you-want-one>
  Like, you remember the case where you modify both X and Y, and the you
  commit the transaction. What's in your system, if Y was not in the
  cache, so when you later get Y the cache will read it directly from
  the repository (so you get the new version of Y from the cache), and X
  was cached but not yet updated with the async. observation event, so
  you get the old version of X from the cache? Hops! You see the old X
  and the new Y together, it didn't helped that observation evens was
  packed into a single bundle.
</example-if-want-one>
Such a solution can't be used unless you can allow some occasional
"Hops!"-es. Not a big deal with HTML templates, OK, but OTOH we are
talking about a general purpose repository here. The whole is like if
Hibernate would sometimes return confused result sets (not obeying to
transaction boundaries). Hibernate users would laugh ("LOL", as you said
;)) and go away, and they would be damn right. So don't ridicule this
issue, just because it's certainly good enough for web page templates.
The fact that you need to store some heavyweight objects (so you will
need that client side cache) doesn't involve that the storage need not
work precisely. It is not the question of little VS big objects, it's
the question of what do you use the repository content for. I mean,
isn't this silly: "Question: Do you have heavyweight objects in the
content repository, that you read frequently? Answer: Yes (e.g. XML
documents). Conclusion: Then you don't need transactions and such "ACID
things", at least it is enough if they only mostly work correctly." So I
agree, this is really "LOL" ;), and the current situation is this.

And now that I have slept one, I start to believe that for this precise
caching the UUID+modificationCounter ("version stamp") will be the good
solution. Think about it, it works even in situations like when you
check in into an earlier version (JCR versioning). And it has to, as
this cache must be transparent in the sense that it doesn't ruin the
precision of the raw JCR. Building the cache on "version stamp" seems to
me simple and straightforward (just use the
path+UUID+modificationCounter as the key in the cache, and that's it).
The only tricky question (that I'm aware of now...) is how to decide if
a cache entry will not be needed anymore.

And before I hear again that it is slow: This cache is not about
decreasing the number of occasions when you read then content repository
with JCR, but about dramatically decreasing the number of occasions when
you have to create "heavyweight" objects (and also substantially
decreasing the number of occasions when you have to read long binary and
string values from the repository). It's basically like a simplified
Hibernate (simplified because it doesn't deals with writing), just it
can map to heavyweight objects too, not just to little beans, which I
think important for content repositories. (Then if you want, you can add
a "non-precise" cache over the precise storage mechanism (that
internally has a precise cache), for the cases where it is acceptable.)

-- 
Best regards,
 Daniel Dekany


Mime
View raw message