Re: [Hibernate] RE: DistributedCacheConcurrencyStrategy

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

I found a pretty good description of the 2 read-write strategy that =
ideally hibernate should support ( the current one and the one i named =
"lightweight read-write" but the good name is optimistic-read-write

a.. The Synchronized Replicated Cache  ensures the coordinated =
synchronization of data across the entire cluster with the guaranteed =
minimum amount of network traffic and support for automatic fail-over. =
Provide thread-safe access and concurrency support for coordinated =
locking on a network. (what we got with centralized lock server)

a.. The Optimistic Replicated Cache sacrifices the cluster-synchronized =
concurrency control mechanism found in the Synchronized Replicated Cache =
in order to provide the theoretical maximum possible throughput of any =
clustered replicated cache implementation. (what i would like to see =
supported too)

Regards, Chris.

  From: Christian Meunier=20
  To: hib...@li...=20
  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:
     =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