Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Message-ID: <40BE125E.30707@mobilebox.pl>
Date: Wed, 02 Jun 2004 19:46:06 +0200
From: Leszek Gawron <lgawron@mobilebox.pl>
User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502)
MIME-Version: 1.0
To: dev@cocoon.apache.org
Subject: Re: AW: JXTG and caching
References: <PIEGKIAINHPDEOEPIPNIMEHDCKAA.m_rolappe@web.de>
In-Reply-To: <PIEGKIAINHPDEOEPIPNIMEHDCKAA.m_rolappe@web.de>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Marco Rolappe wrote:
>>see my example of heavy biz data preparation. Suppose every
>>aggregation part
>>needs another part of bizData. If you make it simple and show
> 
> 
> don't know exactly what you mean with aggregation here. <map:aggregate>
> stuff?
yes

>>cached view only
>>if all parts were still valid it would be hardly usable. If you make it
> 
> 
> if you're talking about <map:aggregate> stuff the aggregate would be
> 'invalid'. the still valid parts wouldn't have to be regenerated, tough.
> thus, only the invalid parts and the aggregate would have to be regenerated.
you're right but I am talking also about biz data provided from flow.

> hard to discuss without a concrete exmaple. another point to note is the
> difference between caching the view data/bizdata and the cacheability of the
> pipeline stage; 
this is what I've been talking from the start. That is why we did not 
understand each other.

> providing JXTG with a key and validity is the one side, i.e.
> telling the pipeline infrastructure whether the cached artifact is still
> valid or has to be regenerated. the other side is the validity of your
> prepared view data (heavy business stuff), which is a different issue. but
> it's also straightforward and should go something like this:
> 
> - controller looks up cached data (view data/heavy business stuff)
For view data this may not be a single cache entry (map:aggregate). what 
then ?

> - if cache entry exists check validity
> 	- if valid
> 		- 'send' cached view data and validity to flow context
> 	- if invalid
> 		- prepare view data
> 		- cache view data
I think cocoon should not cache biz data because:
- it may be memory consuming
- it is double caching really (if you cache the view also)
- you mess with lazily fetched collections(hibernate, ojb):
   * collections retrieve data from backend during view rendering
   * only the needed data is being fetched so you would have to know
     EXACTLY what data the view needs and initialize it before caching.
     This way all the fun of using OR (hibernate) and templates is
     destroyed. When you have a object model with lazy fetching support
     you can extend your view without making ANY changes to the
     controller code as the model gives you access to much more data that
     you need at the moment.

> 		- 'send' view data and validity to flow context
> - if cache entry doesn't exist
> 	- prepare view data
Which part of view data? If your full view data consists of 100 DB 
fetches and only the part that uses 2 has expired? How would you detect 
that?

> 	- cache view data
> 	- 'send' view data and validity to flow context

My regards
	LG