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