hibernate-devel

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

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

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

This is the email:

http://sourceforge.net/mailarchive/forum.php?thread_id=3D1033840&forum_id=
=3D7517
  ----- Original Message -----=20
  From: Gavin King=20
  To: Christian Meunier=20
  Cc: hibernate list=20
  Sent: Thursday, September 19, 2002 9:25 PM
  Subject: Re: [Hibernate] JCS cache - Distributable read-write


  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.

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

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

Thanks Gavin for this !

At this stage of my brainstorming about the cache, if i had to code it, =
the logic would be this:

The Cache interface should be like yours but with a remove method also.

CachedItem would be simplified to :

{
    private long timestamp;
    private Object value
}

ClassPersister would hold a JCSCache instance


Load operation:

The method responsible for loading an object in the session would do the =
following ( very simplified view of the code, just the logic here)

if( cache.get(...) !=3D null) // the item is already in a cache and we =
get it from there
{
        if(CachedItem.getTimestamp() < session.getTimestamp() ) // has =
this cacheditem been put in the cache before the session has begun ?
        {
                //Use the cacheditem to assemble the object
        }
        else
        {
                LoadFromDb()  // load the item from the databaase
                                      // Notice that we do not then put =
the loaded item in the cache       =20
        }
}
else
{
        LoadFromDb()      // Load the item from the database
        cache.put(item)    // put the item in the cache
}

Update/Delete operation:

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

With this logic, we end with a read only cache ( we never update an item =
in the cache) for mutable objects.

Do you see an example where the transaction isolation would fail with =
this logic ?
Do you see why this would not work using a lateral caching in JCS ?

Regards
Christian Meunier

  ----- Original Message -----=20
  From: Gavin King=20
  Cc: hibernate list=20
  Sent: Thursday, September 19, 2002 1:34 PM
  Subject: Re: [Hibernate] JCS cache - Distributable read-write


  This is the email:

  =
http://sourceforge.net/mailarchive/forum.php?thread_id=3D1033840&forum_id=
=3D7517
    ----- Original Message -----=20
    From: Gavin King=20
    To: Christian Meunier=20
    Cc: hibernate list=20
    Sent: Thursday, September 19, 2002 9:25 PM
    Subject: Re: [Hibernate] JCS cache - Distributable read-write


    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.