Re: [Hibernate] RE: DistributedCacheConcurrencyStrategy

[Christian Meunier]

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   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) 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 To: [EMAIL PROTECTED] 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