Why is the SourceValidity isValid( SourceValidity newValidity ) method needed?

[Peter Hunsberger <pe...@gmail.com>]

I'm currently reworking our system to add finer grained cache
normalization and I'm a tad confused as to exactly how Cocoon checks
cache validity.  In particular, as the subject line says, I can't see
why the SourceValidity class needs the capability to check against a
new SourceValidity?

Since the generation of the key is separated from the retrieval of the
validity I can't figure out a use case where you need to further
separate the validity checking?  For Cocoon purposes it seems to me
that, at worse, any validity Cocoon has to deal with may have to wrap
some external validity checks behind a simple isValid() method?  Does
Cocoon ever generate a new validity for checking against an old one?

I suppose the answer might simply be that this is an Excalibur class
that allows for comparisons of validities across clustered servers or
some such thing and that it does nothing specifically for Cocoon?

-- 
Peter Hunsberger

RE: Why is the SourceValidity isValid( SourceValidity newValidity ) method needed?

[Carsten Ziegeler <cz...@apache.org>]

Peter Hunsberger wrote: 
> 
> Just to double check; if isValid() never returns 0 then there's no way
> isValid(SourceValidity) is going to be called?
> 
Yepp.

Carsten

Re: Why is the SourceValidity isValid( SourceValidity newValidity ) method needed?

[Peter Hunsberger <pe...@gmail.com>]

On Mon, 15 Nov 2004 20:53:14 +0100, Carsten Ziegeler
<cz...@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

Re: Why is the SourceValidity isValid( SourceValidity newValidity ) method needed?

[Giacomo Pati <gi...@apache.org>]

On Mon, 15 Nov 2004, Peter Hunsberger wrote:

> On Mon, 15 Nov 2004 19:45:42 +0100, Carsten Ziegeler
> <cz...@apache.org> wrote:
>> Peter Hunsberger wrote:
>>
>>>
>>> I'm currently reworking our system to add finer grained cache
>>> normalization and I'm a tad confused as to exactly how Cocoon
>>> checks cache validity.  In particular, as the subject line
>>> says, I can't see why the SourceValidity class needs the
>>> capability to check against a new SourceValidity?
>>>
> <snip/>
>>>
>> This method is required if the source validity can't tell by
>> itself if it is still valid. For example, if the source
>> validity stores a last modification date of a file (an http
>> request etc.), it can't tell by itself if the resource has
>> changed. In this case the new (current) last modification
>> date is required and the implementation of the source validity
>> would check if they are the same or not.
>> We used to use this for our file based validities for example,
>> until someone had the clever idea to store the file object
>> into the source validity. But if you would only store the
>> last modification date, you need this method.
>
> 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?

Becasue the SourceValidity is just a Validity not the resource the 
validity is about.

> 2) Who generates the new source validity for the second check?  I
> can't see how sequence of methods would be actually invoked...

Either a client class using/managing a resource or the resource itself.

> Storing all the knowledge the validity needs to determine validity
> within the validity itself seems like the only thing that makes sense?

Well, depends on the POV. The Validity is all about validity checks not 
about producing them.


>
>> 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?
>
>

-- 
Giacomo Pati
Otego AG, Switzerland - http://www.otego.com
Orixo, the XML business alliance - http://www.orixo.com

RE: Why is the SourceValidity isValid( SourceValidity newValidity ) method needed?

[Carsten Ziegeler <cz...@apache.org>]

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.

> 
> 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.

> 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 ;)

Carsten

Re: Why is the SourceValidity isValid( SourceValidity newValidity ) method needed?

[Peter Hunsberger <pe...@gmail.com>]

On Mon, 15 Nov 2004 19:45:42 +0100, Carsten Ziegeler
<cz...@apache.org> wrote:
> Peter Hunsberger wrote:
> 
> >
> > I'm currently reworking our system to add finer grained cache
> > normalization and I'm a tad confused as to exactly how Cocoon
> > checks cache validity.  In particular, as the subject line
> > says, I can't see why the SourceValidity class needs the
> > capability to check against a new SourceValidity?
> >
<snip/>
> > 
> This method is required if the source validity can't tell by
> itself if it is still valid. For example, if the source
> validity stores a last modification date of a file (an http
> request etc.), it can't tell by itself if the resource has
> changed. In this case the new (current) last modification
> date is required and the implementation of the source validity
> would check if they are the same or not.
> We used to use this for our file based validities for example,
> until someone had the clever idea to store the file object
> into the source validity. But if you would only store the
> last modification date, you need this method.

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?

2) Who generates the new source validity for the second check?  I
can't see how sequence of methods would be actually invoked...

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?

-- 
Peter Hunsberger

RE: Why is the SourceValidity isValid( SourceValidity newValidity ) method needed?

[Carsten Ziegeler <cz...@apache.org>]

Peter Hunsberger wrote: 
> 
> I'm currently reworking our system to add finer grained cache 
> normalization and I'm a tad confused as to exactly how Cocoon 
> checks cache validity.  In particular, as the subject line 
> says, I can't see why the SourceValidity class needs the 
> capability to check against a new SourceValidity?
> 
> Since the generation of the key is separated from the 
> retrieval of the validity I can't figure out a use case where 
> you need to further separate the validity checking?  For 
> Cocoon purposes it seems to me that, at worse, any validity 
> Cocoon has to deal with may have to wrap some external 
> validity checks behind a simple isValid() method?  Does 
> Cocoon ever generate a new validity for checking against an old one?
> 
> I suppose the answer might simply be that this is an 
> Excalibur class that allows for comparisons of validities 
> across clustered servers or some such thing and that it does 
> nothing specifically for Cocoon?
> 
This method is required if the source validity can't tell by
itself if it is still valid. For example, if the source
validity stores a last modification date of a file (an http
request etc.), it can't tell by itself if the resource has
changed. In this case the new (current) last modification
date is required and the implementation of the source validity
would check if they are the same or not.
We used to use this for our file based validities for example,
until someone had the clever idea to store the file object
into the source validity. But if you would only store the
last modification date, you need this method.

So, in the general this method is imho needed ;)

Carsten