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

[Gavin K. <ga...@ap...>]

Nice diagram! I wish the Hibernate doco had some diagrams like that....

What I mean by "transactional access" is we would have to be able to =
read a value out of the cache, check its timestamp, and then put a new =
value in the cache as an atomic operation. Currently we do this by =
synchronizing on the strategy object. That approach won't work for a =
distributed cache. I detailed an approach that would work (a remote =
LockServer) in a previous email. If you read that carefully you will see =
exactly how isolation would be broken without it.

Gavin
  ----- Original Message -----=20
  From: Christian Meunier=20
  To: hib...@li...=20
  Sent: Thursday, September 19, 2002 4:32 PM
  Subject: [Hibernate] JCS cache - Distributable read-write


  Hi all, well i finally took some times to look at the code ( i really =
should had started by this before asking dumb questions... sorry about =
that) and i have few observations that need some comments/corrections.

  Basically, there are 2 main issues with the cache :

   - First we need to ensure tx isolation as illustrated by the picture.
   - Second the cache need to support pessimistic locking , so we need =
to be able to lock/release object in the cache.

  First issue is solved by comparing 2 timestamps, the former is the =
time when the object was cached and the latter is the time when we =
started the transaction and also by testing if the object is fresh.
  Second issue is addressed by Lock() and Release() method provided by =
the CacheConcurrencyStrategy Interface.

  All the informations that is needed to solve those 2 issues are =
encapsulated in the CachedItem Class, it's this class that is cached in =
the JCS cache.
  All the methods in the ReadWriteCache class are synchronized to avoid =
any race condition with lock() / release() , it's not needed for tx =
isolation.

  Questions:

   - Why distributable read-write cache using lateral jcs cache cant =
work without hacking the code ? i found this answer from Gavin on the =
mailing list:

  "JCS would need to support transactional access to use it for =
distributed "read-write" cache"

  Gavin, could you elaborate a bit this please, i dont see what you =
means exactly.

   - If i am right with my statement regarding the synchronized issue, =
we might want to be able to tell hibernate that we do not need =
pessimistic locking ( where Postgres MVCC is good enough for example) =
and then provide an unsynchronized ReadWriteCache. Now if JCS is not =
thread safe just disregard this comment.

  Thanks in advance
  Christian Meunier