*

Overview Of lrucmgr

  • Overview Of bcfw - lrucmgr uses these interfaces
  • Overview Of filepobc - filepobc uses lrucmgr
  • Overview Of filepobc.test - filepobc.test tests filepobc and lrucmgr
  • This package provides an implementation of the CacheManager and CacheEntry introduced in the BaseCollection Framework (COM.ibm.jaws.services.bcfw). This implementation uses a standard clock algorithm to determine which cached object should be chosen as a victim to keep memory/backingstore resources limited to a predetermined maximum.

    Because a CacheManager is typically used as part of the implementation of BaseCollections, testing for this is in COM.ibm.jaws.services.filepobc.test.

    An LruCacheEntry includes the following cache status information:

    An LruCacheEntry has a reference to 1 ManagedDel which has a reference back to the LruCacheEntry. This same attached ManagedDel is returned to all clients who resolve() to the same object. If a cached object is chosen as a victim, then it deattaches this ManagedDel by setting the ManagedDel's reference to its LurCacheEntry to null. The LruCacheManager then returns the LruCacheEntry to the BaseCollectionEC using the uncached() method, so it can write it out to disk if it is dirty. The ManagedDel will then be collected after all client references go away, and the Cached object will be collected after the BaseCollectionEC is finished with it.

    The hottest objects typically are not claimed by the Lru clock algorithm, so the object may be out of sync with the disk (dirty) for a long period of time. To minimize the possibility of data loss, the BaseCollectionEC implements some policy for cleaning objects. In some cases, the BaseCollectionEC may decide to override the Lru clock algorithm based on its knowledge of usage (eg, scan optimization) and remove objects from the cache. The LruCacheManager can accomodate any such policy via the LruCacheManager's uncacheObject() methods and the LruCacheEntry cleaned() method. This separation of concerns is typical in database and file systems.

    An LruCacheManager maintains a java Hashtable for all cached objects that provides an efficient mapping between the cacheKey and the LruCacheEntry. The cacheKey includes a transient id for the BaseCollectionEC and the Managed object's key within that BaseCollectionEC, so that all LruCacheEntrys are uniquely identified within the LruCacheManager. The transient id for a BaseCollectionEC is the string form of an integer that is incremented each time a new BaseCollectionEC asks the LruCacheManager to cache its first object. These transient ids are much more efficient that the BaseCollectionEC's persistent Identifier and only need to work within a single activation of an LruCacheManager instance. An LruCacheManager maintains a java Hashtable for all of these transient ids that provides an efficient mapping between the BaseCollectionEC object and the transient id.

    An LruCacheManager keeps the number of Cached object within its maxNumberEntries. This maxNumberEntries can be changed dynamically during a single activation of an LruCacheManager instance for performance tuning.

    An LruCacheManager is packaged as a Manageable class, so that it can be either manually managed or managed by a BaseCollection.