cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Peter Hunsberger" <peter.hunsber...@gmail.com>
Subject Re: JNet integration
Date Wed, 26 Mar 2008 14:00:13 GMT
On Wed, Mar 26, 2008 at 4:46 AM, Carsten Ziegeler <cziegeler@apache.org> wrote:

<snip/>

>  The question is now if we need support for caching in the low level apis
>  or if it is possible to have a layered approach - which would make the
>  entry barrier much easier.
>

We've ended up layering our own caching on top (or maybe under,
depending on your POV) of much of the Cocoon caching.  This is because
we mainly use a single generator and serve most of our content from a
database.  In our case different database resources have very
different cache lifetimes, we have very granular resources with very
aggressive caching (very simplified example; metadata and data is
pulled from the same pipeline.)  Basically I've found a couple of
things:

- Cache key construction is the thing that matters.  We allow
polymorphic behavior in the cache keys so that multiple resources can
resolve to the same resource.  It is up to the cache key to determine
what underlying resource is being accessed and not the URI.

- Since we allow cache key polymorphisim we cannot use a Hashmap since
a hash code look up doesn't allow two objects with different hash
values to occupy the same object space. Instead we use a TreeMap that
tests equality explicitly, a seperate equality test can use whatever
rules it needs.

- all of the call context is made available for the cache key
construction, we make no assumptions on how the cache key is going
manage itself, there is no such thing as different types of cache keys
any cache key might be based on time to live, events, URI, request
parameters and attributes, or whatever.

- cache keys can register other cache keys that they are dependent on
and invalidating a cache key causes resources defendant on it to also
be invalidated.  The important thing here is that all caching
decisions are contained in a single place (the cache key).

- all resource access goes through the same path.  Non cached
resources simply do not get a cache key, if no cache key is built the
attempt to retrieve the resource from the cache is skipped (duh).

Don't know if this helps any, but for us, having made this design
decision our caching is completely decoupled form URI resolving (and
in fact the rest of the Cocoon infrastructure).

-- 
Peter Hunsberger

Mime
View raw message