Sent: Tuesday, September 24, 2002 5:53
AM
Subject: [Hibernate] RE:
DistributedCacheConcurrencyStrategy
Little more input on the subject:
I thought how to achieve maximum flexibility
and keep a clean code for the cache, i came up with the following design
that makes more sense IMHO than using a
DistributedCacheConcurrency:
(1) Define a lockserver interface
(2) Implement a local lockserver
(3) Implement a centralized
lockserver
(4) Optionally implement a distributed
lockserver ( the one i actually did but i believe centralized one
makes more sense)
(5) Refactor the
ReadWriteCacheConcurrency:
(a) Remove Synchonized
methods
(b) use the lockserver
interface
(6) Refactor the <jcs-cache> tag so we
can:
(a) Specify a strategy to
use ( either "read-only" or "read-write" or a full class name
"com.foo.MyCacheConcurrencyStrategy" )
(b) Optionally specify
a lockserver to use ( either "local" or "centralized" or a full class name
"com.foo.MyLockServer" )
(7) Add a remove method to the Cache interface
so we allow implementation such the proposed "lightweight readwrite" ( see
my previous email) to use it. Clearly state in the javadoc tag that using
this method an implementation can not fully ensure tx isolation in all
case.
At the end we should end with a pretty strong
and plugable cache in Hibernate ;)
Another topic:
What is the correct behaviour regarding the
lockserver, i believe i did something wrong in the distributable
prototype, i mean when we try to acquire a lock and the server responds
saying the object is already locked. Should we then go to the database (
what i currently do ) or wait and retry.
I believe the latter is the correct
answer.
Best regards
Christian Meunier