6.1.1 Disk cache enhancements
As more objects get stored on the disk, we need to limit the size or number of entries that are on disk, and we need to have greater control over what gets put on disk and what the behavior is when the disk is full.
The total number of objects that need to be cached and size of these objects often imply that the primary store for these objects is the disk. The changes are the following:
| A new option has been provided to use the disk cache as primary object store (per cache instance and per cache entry). |
|
| You can specify objects to be pinned in memory per cache entry based on the expected frequency of use. |
|
| In the past, administrators have been concerned about the impact of DynaCache on memory usage, and its effect on the performance of their systems. A new feature provides a mechanism to allow the administrator to tune the amount of metadata that is kept in memory for more efficient cache access and general book-keeping in order to reduce perceived outages during background DynaCache activity. |
|
| The programmer or solution architect can specify advanced caching criteria in the application's cache policy. |
|
| You can exclude a child fragment from full page caching and that child fragment is not to be cached as a separate fragment. |
|
| You can selectively cache cookies along with the response. The existing `store-cookies' property saves all the cookies. |
|
| You can define a cache policy based on the range of values for a given parameter or attribute. |
|
| You can choose to not use the cache under certain conditions (skip-cache), for example, to support the retrieval of preview content. |
|
| Disk cache size is configurable, to limit the offload to disk. This has meant implementing changes to the disk eviction algorithm so that it kicks in at some threshold value before the disk cache fills up and keeps space available. |
|
| Administrators are allowed to specify an upper bound on the size of a single entry that is stored in the cache. Larger sized objects will still be managed for invalidation propagation. |
|
| Contention for cache was reduced by re-evaluating synchronization of resources in cache. |
|
| Deletion time for entries on disk cache was reduced by reorganizing disk layout to separate metadata (dependencies) that group objects together for invalidation from the actual serialized data. |
|
| Disk scan times for expired entries on disk were reduced. |
The following sections describe the latest developments and changes made to DynaCache. Be aware, however, that the majority of these new features have been backported to WebSphere Application Server v5.0.2.18, v5.1.1.13, and v6.0.2.17 and above.