Re: [Hibernate] Re: [Hibernate-devel] distributed caching

[Christoph S. <ch...@mc...>]

Hey Christian!

What I am trying to achieve is a distributed read-write cache. I didnt
explicitly mention it in my post, but from the context (i was mentioning
writes) it could be guessed. I think Gavin understood me better because we
had a conversation about distributed read write caches before.

Sorry if I wasnt precise enough.

regards
 christoph

----- Original Message -----
From: "Christian Meunier" <vc...@cl...>
To: "Christoph Sturm" <ch...@mc...>;
<Gavin_King/Cirrus%CI...@ci...>
Cc: <hib...@li...>
Sent: Wednesday, September 04, 2002 5:50 PM
Subject: Re: [Hibernate] Re: [Hibernate-devel] distributed caching


> I must miss something here....
>
> I dont understand why in a read only cache ( what Christoph is trying to
> achieve) you need a transaction aware distributed caching.
> As i understand read only cache behaviour, when you read an object from
the
> database, cache it, whe you update/delete an object, flush it from the
> cache, right ?
>
> Gavin could you please show me an example where the isolation of
transaction
> could be broken without a transaction aware distributed caching please ?
>
> Regards
> Christian Meunier
>
> ----- Original Message -----
> From: <Gavin_King/Cirrus%CI...@ci...>
> To: "Christoph Sturm" <ch...@mc...>
> Cc: <hib...@li...>
> Sent: Wednesday, September 04, 2002 5:03 PM
> Subject: [Hibernate] Re: [Hibernate-devel] distributed caching
>
>
> >
> > Hi Christoph sorry about the slow ping time. It takes a while to collect
> > thoughts and write a response to some of these things.....
> >
> > >>> Yesterday I was thinking about implementing a distributed cache for
> > Hibernate. I want each node to have its own cache, but if one node
writes
> > to its db the data should be invalidated in all caches. You once
mentioned
> > that hibernate would need a transaction aware distributed cache to
support
> > distributed caching.
> > I dont get why this is necessary. Can you tell me what kind of problems
> you
> > think i will run into when trying to implement such a beast, and where
you
> > think I could start?
> >
> > I was thinking about using jcs as cache, and when a session is
committed,
> > just invalidate all written objects in the cache. <<<
> >
> > If you have a look over cirrus.hibernate.ReadWriteCache you'll see that
> > theres some interesting logic that ensures transaction isolation is
> > preserved. A cache entry carries around with it:
> >
> > (0) the cached data item if the item is fresh
> > (1) the time it was cached
> > (2) a lock count if any transactions are currently attempting to update
> the
> > item
> > (3) the time at which all locks had been released for a stale item
> >
> > All transactions lock an item before attempting to update it and unlock
it
> > after transaction completion.
> >
> > ie. the item has a lifecycle like this:
> >
> >                                  lock
> >                                <---------
> >   ------> fresh ------> locked ---------> stale
> >     put          lock           release
> >
> > (actually the item may be locked and released multiple times while in
the
> > "locked" state until the lock count hits zero but the difficulty of
> > representing that surpasses my minimal ascii-art skills.)
> >
> > A transaction may read an item of data from the cache if the transaction
> > start time is AFTER the time at which the item was cached. (If not, the
> > transaction must go to the database to see what state the database
thinks
> > that transaction should see.)
> >
> > A transaction may put an item into the cache if
> >
> >  (a) there is no item in the cache for that id
> >               OR
> >  (b) the item is not fresh AND
> >  (c) the item in the cache with that id is unlocked AND
> >  (d) the time it was unlocked BEFORE the transaction start time
> >
> > So what all this means is that when doing a put, when locking, and when
> > releasing, the transaction has to grab the current cache entry, modify
it,
> > and put it back in the cache _as_an_atomic_operation_.
> >
> > If you look at ReadWriteCache, atomicity is enforced by making each of
> > these methods synchronized (a rare use of synchronized blocks in
> > Hibernate). However, in a distributed environment you would need some
> other
> > kind of method of synchronizing access from multiple servers.
> >
> > I imagine you would implement this using something like the following:
> >
> > * Create a new implementation of CacheConcurrencyStrategy
> > -DistributedCacheConcurrencyStrategy
> > * DistributedCacheConcurrencyStrategy would delegate its functionality
to
> > ReadWriteCache which in turn delegates to JCSCache (which must be a
> > distributed JCS cache, so all servers see the same lock count +
> timestamps)
> > * implement a LockServer process that would sit somewhere on the network
> > and hand out very-short-duration locks on a particular id.
> > * DistributedCacheConcurrencyStrategy would use the LockServer to
> > synchronize access to the JCS Cache between multiservers.
> >
> > Locks would be expired on the same timescale as the cache timeout (which
> is
> > assumed in all this to be >> than the transaction timeout) to allow for
> > misbehaving processes, server failures, etc.
> >
> > Of course, any kind of distributed synchronization has a *very* major
> > impact upon system scalability.
> >
> > I think this would be a very *fun* kind of thing to implement and would
be
> > practical for some systems. It would also be a great demonstration of
the
> > fexibility of our approach because clearly this is exactly the kind of
> > thing that Hibernate was never meant to be good for!
> >
> > :)
> >
> > Gavin
> >
> >
> >
> > -------------------------------------------------------
> > This sf.net email is sponsored by: OSDN - Tired of that same old
> > cell phone?  Get a new here for FREE!
> > https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390
> > _______________________________________________
> > hibernate-devel mailing list
> > hib...@li...
> > https://lists.sourceforge.net/lists/listinfo/hibernate-devel
> >
> >
>
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by: OSDN - Tired of that same old
> cell phone?  Get a new here for FREE!
> https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390
> _______________________________________________
> hibernate-devel mailing list
> hib...@li...
> https://lists.sourceforge.net/lists/listinfo/hibernate-devel
>