This document discusses the NetKernel cache architecture and how to develop new cachelet implementations. The cache architecture is extensible through the addition of cachelets, small additions to the cache architecture that act as either local module-level or fallback global caches.

Cache Resolution

Cachelet implementations are declared in a module.xml file by specifying the Java classname of the implementation inside a <cache> element:

The implementation class may located in the module or one that is imported from a library module.

NetKernel determines the appropriate cachelet to use for a request by first looking for a cachelet specification in the current module. If one is not located, the request call-stack is traversed to locate a parent module with a cache declaration. If no cachelets are found, the default global NetKernel cache is used. The default, global NetKernel cache is configured in the System Configuration File.

Interaction with Requests

The NetKernel scheduler attempts to cache the results of all SOURCE and TRANSREPRESENT requests. Requests of type DELETE and SINK must invalidate any preexisting cached results.

Resources are cached with a primary key that includes their request context. The request context is the unique local environment for the request and includes the origin module and it's superstack address space.

When a request is resolved by NetKernel it looks first for a valid cached resource representation before invoking an accessor. If an accessor is called, the returned resource representation is placed in the cache.

Metadata

Cache implementations may use the metadata associated with a resource representation to effect the behaviour of items in the cache. The following tables gives some details:

field	description
isExpired()	Expired resources should not be placed in a cache and if they expired while in the cache, should never be returned from a cache.
isIntermediate()	This is a hint that a resource should not be cached because it is an intermediate part of a computation. The final result of the computation is instead a candidate for the cache.
getPessimisticExpiryTime()	When a resource is served to a remote client, the client may not have access to live metadata on a resource. This value serves as the period during which a client can assume the resource will remain valid (not expired). A practical example of this is when resources are served over a HTTP connection to a browser. This field maps into the HTTP header field "Expires" which allows clients and intermediate caches to cache the resource.
getCreationCost()	The relative cost of recreating a resource.
isContextSensitive()	When true, a resource depends upon the context of a request (the request callstack) it must be carefully keyed to ensure it is only returned to clients with the same context, or not cached at all.

Developing

Examine the source code of the cache implementations in the cache-standard module for examples.