Re: [Hibernate] RE: DistributedCacheConcurrencyStrategy

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

I *finally* had a chance to look over your work on this: pretty cool, I like
it. Not yet convinced that we want to introduce a JavaGroups dependency into
the main codebase, but you could work on me and I might capitulate :)

> 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: [snip]
> (6) Refactor the <jcs-cache> tag so we can: [snip]

Yup, all thats quite acceptable.

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

Sounds reasonable.


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

Nope, we should go straight to the database. Hibernate threads never ever
wait for each other.

Thanks Christian, sorry for not addressing this sooner. Just been *very*
busy.....