hibernate-devel

[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

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

Re: [Hibernate] RE: DistributedCacheConcurrencyStrategy

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

Do you have a reference (URL) for this?

sorry ... I still havn't looked at your other emails......refactoring =
continues....
  ----- Original Message -----=20
  From: Christian Meunier=20
  To: hib...@li...=20
  Sent: Tuesday, September 24, 2002 4:14 PM
  Subject: Re: [Hibernate] RE: DistributedCacheConcurrencyStrategy


  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

Re: [Hibernate] RE: DistributedCacheConcurrencyStrategy

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

Here you go
--> http://www.tangosol.com/products-clustering-overview.jsp

Found a nice diagram that we could hack a bit to explain centralized =
lockserver
--> http://www.fastobjects.com/images/FO_ActiveCaching.gif=20
  From: Gavin King=20
  To: Christian Meunier=20
  Cc: hibernate list=20
  Sent: Tuesday, September 24, 2002 10:14 AM
  Subject: Re: [Hibernate] RE: DistributedCacheConcurrencyStrategy


  Do you have a reference (URL) for this?

  sorry ... I still havn't looked at your other emails......refactoring =
continues....

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

Re: [Hibernate] RE: DistributedCacheConcurrencyStrategy

[Jon L. <jon...@xe...>]

Hi,

I myself really like the idea of the DistributedCacheConcurrency.  (Of
course, I'm being a little selfish since I have an immediate use for it.)
Christian, if you need any help to finish, and/or test it, please let me
know.  I have an application already written which would be a good test for
this.

Gavin, since your hesitant to add yet another dependency into the codebase,
have you thought about adding a "hibernate-optional.jar" to the project that
could contain non-core, but useful things like this?

Jon...

----- Original Message -----
From: "Gavin King" <ga...@ap...>
To: "Christian Meunier" <vc...@cl...>
Cc: "hibernate list" <hib...@li...>
Sent: Sunday, October 06, 2002 7:13 PM
Subject: Re: [Hibernate] RE: DistributedCacheConcurrencyStrategy


> 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.....
>
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> hibernate-devel mailing list
> hib...@li...
> https://lists.sourceforge.net/lists/listinfo/hibernate-devel
>

Re: [Hibernate] RE: DistributedCacheConcurrencyStrategy

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

Aah, if we need to include the JavaGroups jar, we need to include it.

I made a change to the caching stuff last night that will have an impact
upon you guys. Previously, we distinguished "before" and "after" by looking
at System.currentTimeMillis(). I've added cirrus.hibernate.cache.Timestamper
which generates 'timestamps' that are much more fine-grained than
System.currentTimeMillis(), so that cache hits will be more likely. The new
'timestamps' are only safe in a single VM, so you guys will have to figure
out what to do in a distributed cache. (In fact, the old mechanism which
used System.currentTimeMillis() was also non-safe for a distributed cache.)
I guess we would need the lockserver to generate timestamps somehow..... I'm
not sure of the details of this, or the performance implications (hitting
the lockserver at the start of every session???).


----- Original Message -----
From: "Jon Lipsky" <jon...@xe...>
To: "Gavin King" <ga...@ap...>; "Christian Meunier"
<vc...@cl...>
Cc: "hibernate list" <hib...@li...>
Sent: Monday, October 07, 2002 4:14 PM
Subject: Re: [Hibernate] RE: DistributedCacheConcurrencyStrategy


> Hi,
>
> I myself really like the idea of the DistributedCacheConcurrency.  (Of
> course, I'm being a little selfish since I have an immediate use for it.)
> Christian, if you need any help to finish, and/or test it, please let me
> know.  I have an application already written which would be a good test
for
> this.
>
> Gavin, since your hesitant to add yet another dependency into the
codebase,
> have you thought about adding a "hibernate-optional.jar" to the project
that
> could contain non-core, but useful things like this?
>
> Jon...
>
> ----- Original Message -----
> From: "Gavin King" <ga...@ap...>
> To: "Christian Meunier" <vc...@cl...>
> Cc: "hibernate list" <hib...@li...>
> Sent: Sunday, October 06, 2002 7:13 PM
> Subject: Re: [Hibernate] RE: DistributedCacheConcurrencyStrategy
>
>
> > 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.....
> >
> >
> >
> >
> > -------------------------------------------------------
> > This sf.net email is sponsored by:ThinkGeek
> > Welcome to geek heaven.
> > http://thinkgeek.com/sf
> > _______________________________________________
> > hibernate-devel mailing list
> > hib...@li...
> > https://lists.sourceforge.net/lists/listinfo/hibernate-devel
> >
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> hibernate-devel mailing list
> hib...@li...
> https://lists.sourceforge.net/lists/listinfo/hibernate-devel