There ara number of use cases. 1. Read only objects, cache unlimited. They shouldn't be locked, so for them distributed cache should work just broadcasting updates. 2. cache time-limited objects should just ignore distributed updates. 3. Database-Locked access should be reread every time from database, another why they are db-locked. 4. Long transactions via timestampable interface should be invalidated, because their master record changed. 5. Pessimistic transaction in case of distributed cash should acquire distributed lock using shared table or broadcasting. This will be slow. 6. It will be nice to implement optimistic transaction which will copy object into local transaction session and merge them back into main cache on commit. Drawback is copying objects.
Again distributed cache is not for objects which will be changed every millisecond. Those should be reread from database. Thanks Ilia --- Thomas Yip <[EMAIL PROTECTED]> wrote: > Hi Ned, > > > The LRU implementation itself is only a Hashtable > replacement > that expires the least recently used objects. > > However, simply clearing what is in the LRU is > certainly not > enough to implement cache eviction, not to mention > distributed > cache. Because object that should be evicted might > be kept in > locks. However, those locks can't be evicted > forcefully. Because, > transaction using it depends on it. And, it needs > the values of > the locked object in all phrases of transaction, and > it should > not be removed or have its values change at all. > LockEngine > is designed just for that. > > So, the problem is not to replace LRU cache, but > implements > cache purging policy inside LockEngine. The policy > must aware > of transaction, and doesn't influence them. At the > same time, it > must make sure in the end of those transaction all > locks and > cache of the evicting object are actually cleared. > The next step is to make cache-purging policy > pluggable. > > LRU cache and distributed cache sounds similar, but > they > don't interchange each other. > > > > Thomas > > -----Original Message----- > >From: Ned Wolpert > [mailto:[EMAIL PROTECTED]] > >Sent: Tuesday, April 30, 2002 9:07 AM > >To: [EMAIL PROTECTED] > >Subject: Re: [castor-dev] Strategy Proposal (repost > - was: Castor JDO > Status) > > > >-----BEGIN PGP SIGNED MESSAGE----- > >Hash: SHA1 > > > >> From: "Thomas Yip" <[EMAIL PROTECTED]> > >> Date: Mon, 29 Apr 2002 18:28:16 -0700 > >> > >> For example, should distributed cache, and local > cache put > >> together. Sound like it is, right? But, I don't > think so. In my > >> opinion, distributed cache should be implemented > as cache > >> purging policy. It should actually not part of > cache > >> implementation, and they shouldn't be put > together. > > > >I want to see about clarification on this issue, > since this is > >specifically important to me. I've argued that > caching systems should > >be 'plug-in'. Meaning, an API for the cache is > defined, and a factory > >object exists that can be referenced in the > castor.properties file of > >which cache factory to use to get the cache. The > API needs to allow > >for multiple caches from the one factory (LRU count > versus > >time-limited) but allows the implementation to > vary. This opens open > >implementation to other developers. > > > >I understand that the main affect we need for a > distribute cache is > >simply the ability to remove objects from the > cache. That way, one > >can build a distributed system to allow this. > However, for me, that > >is only the beginning. Regardless; I would like to > propose a change > >to the current caching system... rather than make > the cache system > >'private' and fixed in the current implementation, > allow me to make > >modifications that would open the api for a > 'plugable' cache system. > >Castor out-of-the-box would see no change; but > allow for developers to > >add in their own caching system. > > > >Comments? (I've been dying to do this for a long > time) > > > >- -- > > > >Virtually, > >Ned Wolpert <[EMAIL PROTECTED]> > > > >D08C2F45: 28E7 56CB 58AC C622 5A51 3C42 8B2B 2739 > D08C 2F45 > >-----BEGIN PGP SIGNATURE----- > >Version: GnuPG v1.0.6 (GNU/Linux) > >Comment: Public key at http://www.keyserver.net > > > >iD8DBQE8zsEoiysnOdCML0URAkuzAJ9g5QKUEYfZ2a2fwqp115b1P6LeWwCffIsk > >YuIc5AYbLiqUJVbWaQ8ldgY= > >=MDyL > >-----END PGP SIGNATURE----- > > > >----------------------------------------------------------- > >If you wish to unsubscribe from this mailing, send > mail to > >[EMAIL PROTECTED] with a subject of: > > unsubscribe castor-dev > > > > ----------------------------------------------------------- > > If you wish to unsubscribe from this mailing, send > mail to > [EMAIL PROTECTED] with a subject of: > unsubscribe castor-dev > __________________________________________________ Do You Yahoo!? Yahoo! Health - your guide to health and wellness http://health.yahoo.com ----------------------------------------------------------- If you wish to unsubscribe from this mailing, send mail to [EMAIL PROTECTED] with a subject of: unsubscribe castor-dev
