cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hunsberger, Peter" <>
Subject RE: Accessing cache validities from flow
Date Wed, 17 Dec 2003 23:37:22 GMT
Stefano Mazzocchi <> writes:

> On 16 Dec 2003, at 11:09, Hunsberger, Peter wrote:
> > Stefano Mazzocchi <> writes:
> >>  Now, the problem is: if I am not the one who generates 
> the validity 
> >> (in linotype, it's the directory generator), how can I 
> invalidate it? 
> >> how can I have access to it?
> >
> > We use data classes that generate the keys for the generators and 
> > whoever else needs them.  Each data class used by a generator has a 
> > way of getting a key string that is unique to the business logic 
> > requirements of that type of data.  If you're updating the data you 
> > can call that method to find out what needs to be invalidated.
> Yeah, but this means that you are in control of the caching logic.... 
> and I'm not if I use "off the shelf" cocoon sitemap components.
> The solution to this problem in the past has been "write your own 
> component".... or "extend cocoon components".
> Don't know about you, but I'm getting more and more accostumed to the 
> "screw the compiler, use scripting" attitude, blame my utter lazyness 
> or blame a classloader that doesn't load a class directly from source 
> passing it thru the eclipse compiler (which would be totally cool for 
> development, BTW)
> The above means that "write your component" triggers some 
> "gosh, can't 
> I do that without code?" kinda attitude that cocoon spoils 
> you so much 
> with.

The data wrappers can be pretty thin if you've got good naming
conventions and data organizations.  It's a bit of a pain because you
end up having many levels of caching (eg. stuff common across
organization, stuff common across departments, cachable for individuals,
not cacheable, etc) and you then need to aggregate all these things.
Your generators end up being organized by cache availability levels and
not by any normal business logic, rather counter intuitive. 

There's probably a generic type solution for file based repositories
where the wrapper would just pick up the directory name and/or file name
then a matching generator could use these classes to automatically wrap
everything.  Not sure how you'd get generic behavior on the invalidation
side however; obviously picking up the key is the same, but now you're
looking at an action handler or flow class figuring out that cache
invalidation needs to be done and knowing that in a generic sense...

> >> I'm starting to think that the cocoon cache needs a 
> serious redesign 
> >> to deal with these issues... and this scares me :-( but 
> it's *waay* 
> >> too important to let go.
> >>
> >> Thoughts?
> >
> > You may recall I've been pushing for this for a year or so 
> now...  Our 
> > needs are perhaps a little orthogonal to the average Cocoon 
> user (or 
> > just extreme), but this gets back to the discussion on push-pull 
> > parsers and having a single normalized repository for all 
> cache items.
> What you were talking about is a content repository. JSR 170 
> expresses 
> *exactly* what you need and implements observation.
As long as it's a light weight repository that would be ok; in our case
everything is already fed from a relational database and EJB's...
Basically I'd want to be able to populate the repository on a "on
demand" basis, though prepopulating for known hot spots would also be

> Note: push/pull parsing and normalized repository for content storage 
> are *orthogonal* issues, independend and separate concerns.

Hmm, perhaps? Certainly they both can address similar performance
concerns.  The reason I'd relate them is because I'm still wondering if
it doesn't make sense to feed the parser directly from the cache, (the
cache then being a collection of PSVI type objects).  That's certainly a
different direction from JSR 170 and would tie Cocoon very tightly to
Cocoon a specific parser (though the whole thing could still be
generically useful).  Probably still too radical so I'll keep quite on

> Please, keep them so: I see no value in restructuring the 
> entire cocoon 
> application using pull parsing.... what you need is XQuery support on 
> top of the repository, then everything can happen in push as 
> we always 
> did (and we are addressing this with JSR 170!)
Really I suspect that we don't even need Xquery: if an XSLT document
request can hit an in memory repository with good performance then
99.99% of our needs will be met...

> > Lots of
> > discussion on this in the past; no forward movement here 
> (I'm finally 
> > getting to bringing 2.1.3 up) but I may have some time to try and 
> > discuss more.
> I think caching, observable repositories and pull parsing are 
> orthogonal issues, so let's keep them separate and focus on 
> caching at 
> the moment.

I'll probably have to be pretty quite on the whole discussion, not a lot
of time for much else (as usual, sigh)...

View raw message