Re: [Hibernate] JCS cache - Distributable read-write

[Christian M. <vc...@cl...>]

>
> > --> The session hold a set of the items that have been updated/deleted
in
> the transaction,
> > when the transaction commit, we iterate the set and remove each entry
from
> the cache.
>
> but merely removing is not enough, because after removal, another
> transaction (that started *earlier*) could come along and try to write
stale
> data in the cache because the database is actually free to return stale
data
> to a read operation. Thats the reason for the more complicated logic in
> read-write cache. What you have to ensure is that a transaction that
writes
> to the cache _started after the completion_ of the transaction that
removed
> the object from the cache. (This is what the current read-write cache
does.)

Haaa all is clear now ;)
I am planning to use hibernate is a kinda very large CMS portal and i intend
to rely on the cache as much as i can ( a la Jive, using only iterator no
bulk loading to maximise the cache use) hence my interest and need to fully
understand how the cache is handled internally.

I am a bit scared by all the synchronized method, even the "read" one is
synchronized....
Are we absolutly sure we need to synchronize the read method ? the
CachedItem contains pretty simple value that basically have 2 states ( the
timestamp is either -1 or a value (set/unset), the cached value is either
null or a value ( staled / fresh )). I tried to find an example where a
read/write conflict ( either the read thread is pre empted and the write
start or vis-versa) could lead to a bad cache state and i could not find
one.

> > With this logic, we end with a read only cache ( we never update an item
> in the cache) for
> > mutable objects.
>
> I don't understand how this is different to the existing read-write cache
> which actually doesn't allow *update* of a cached item, it only allows
> removal from the cache when an object is updated.

Ya you right, it's the same.

>
> There seems to be three types of cache:
>
> Type 1:
> you can add an item
> you can't remove an item
> you can't update an item
>
> Type 2:
> you can add an item
> you can remove an item (when you attempt to update it on the DB)
> you can't update an item
>
> Type 3:
> you can add an item
> you can update an item (when you *know* you have updated its persistent
> state)
>
> Hibernate supports Type 1 (read-only) and Type 2 (read-write) but not Type
> 3. Type 3 would require Hibernate to know whether or not a transaction is
> successful (which it doesn't, in general).

IMHO, Type 2 should really not be named "read-write" because we end
referencing it by a read-write cache where it's instead a read only cache
for read-write objects. A read-write cache is the type 3. For example,
pretty much every JDO implementation got a factory wide cache (type 2, same
purpose as the hibernate one) and they all call it "read only cache" because
the cache is read only, we never update an object in it.

>
> I'm not convinced that what you are implementing is different to Type 2
> (except that it seems to have some holes...)

You are right, once the holes are fixed, i end with the same thing as you.

Thanks for your help Gavin, i really appreciate.
Kind regards
Christian Meunier