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: Why is the SourceValidity isValid( SourceValidity newValidity ) method needed?
Date Mon, 15 Nov 2004 20:43:11 GMT
On Mon, 15 Nov 2004 20:53:14 +0100, Carsten Ziegeler
<cziegeler@apache.org> wrote:
> Peter Hunsberger wrote:
> > I'm still confused:
> >
> > 1) Why can't the validity itself figure out whatever it needs to know.
> >  Eg, go look at the file to see if has been modified?
> 
> The validity object is just a value object - it has to be serializable
> in order to be stored persistently by the cache.
> Sure, you could store e.g. the file name in the object and inside
> the isValid() method open the file etc. But what about resources
> fetched via http or any other protocol? You start mixing value
> objects and controls.

Perhaps so, it's not something we'd run into in our system. in our
case we've got a seperate class (and interface) that takes care of the
association of the validity with data sources.  This class has methods
that can directly interegate our cache manager to check validity: it
our cache on our side is no longer valid then the Cocoon validity is
no longer valid.  This may seem like redundant caching, but we have
cases where our cache management and invalidation runs orthogonal to
Cocoon caching: Eg. objects cached by userid but invalidated by
groupid.
 
> >
> > 2) Who generates the new source validity for the second
> > check?  I can't see how sequence of methods would be actually
> > invoked...
> > 
> It's the source that generates the validity objects. For example
> for a file you end up with a file source object that generates
> the validity object containing the last modification date of the
> file.
> In the case of caching, e.g. the file generator resolves a source
> object for the given source and asks this source object for
> a validity object. This validity object is then stored in the
> cache. With any further request, the validity object is fetched
> from the cache and the isValid() method is invoked. If this
> method is not able to determine if the cached response is still
> valid or invalid it returns the constant for UNKNOWN. If it's
> unknown the file generator is asked to deliver a new validity
> object which is then passed into the isValid(SourceValidity)
> method.
 
Ok, I think this really answers my question.  The way our system works
we can always check on the first call.  In general I think this is
true: since the Setup method can resolve a source it could arrange for
isValid() to do the same work, but having isValid(SourceValidity)
implemented removes the responsibility for coding up the check in
every generator that might need it.

> > Storing all the knowledge the validity needs to determine
> > validity within the validity itself seems like the only thing
> > that makes sense?
> >
> > > So, in the general this method is imho needed ;)
> >
> > I'll take your word for it, perhaps the real question is, if
> > I'm implementing a caching generator what do I really need to
> > worry about?
> > 
> :) You just have to implement the correponding interface that
> makes the component cacheable. The objects you return by the
> methods of this interface should be serializable. If you
> implement your own source validity object make sure that either
> isValid() works or isValid(SourceValidity) works ;)

Just to double check; if isValid() never returns 0 then there's no way
isValid(SourceValidity) is going to be called?

-- 
Peter Hunsberger

Mime
View raw message