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
