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" <[EMAIL PROTECTED]> To: "Christoph Sturm" <[EMAIL PROTECTED]>; <Gavin_King/[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> 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/[EMAIL PROTECTED]> > To: "Christoph Sturm" <[EMAIL PROTECTED]> > Cc: <[EMAIL PROTECTED]> > 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 > > [EMAIL PROTECTED] > > 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 > [EMAIL PROTECTED] > 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 [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/hibernate-devel
