[Hibernate] RE: DistributedCacheConcurrencyStrategy

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

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:
   =20
     (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" )
   =20
(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    =20