cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Antonio Gallardo" <agalla...@agssa.net>
Subject Re: [SUMMARY] Caching DynamicSelectionList
Date Tue, 31 May 2005 13:26:21 GMT
On Mar, 31 de Mayo de 2005, 8:04, Vadim Gritsenko dijo:
> Antonio Gallardo wrote:
>> THE SOLUTION
> ...
>> Our proposed solution is add a new user defined attribute, called
>> "cache"
>> in <fd:selection-list>. This way the cform user can decide when he wants
>> to use a cached DSL or not. For SSL this attribute has no meaning.
>
> Three questions:
>
>   (1) What is cached? What is the structure of cached object.

We will cache a SaxBuffer of the selection-list.

>   (2) WRT to (1), how to cache selection list for a longer time
>       period than for single request? e.g., for (a) session
>       duration, (b) for predefined time interval.

This was not considered. I think we should discuss this.

>   (3) Why you do not cache output of the pipeline producing
>       selection list?

Yep. We do that. See reply to (1).

> I'd suggest trying (3) first before considering any other changes.
>
> There is NO db application where data could not be cached for some time
> period.
> That's in the nature of the database: as soon as you read up your
> selection
> list, it is already stale (there is no guarantee that somebody had not
> changed
> it already), so why not cache it for a bit longer?

Because in the next request we want to check we are using the lastest
changes. In some cases is not a good idea to cache SL longer than in the
same request. I already saw a big performance improvement inside repeaters
and I will be glad to implement this first before do deeper changes.

> And as far as caching goes, there are more usecases for the caching for
> session duration or fixed time interval, IMHO, than for request duration.

Dunno if per session is a good idea. While we know there are some SL that
does not change too much. When a change is posted, the user expect to see
the change in the next request. This is how the things works in most
applications today.

> So caching, if implemented at all, should be flexible enough to
> accomodate different use cases:

> shared lists (with timed expiration),

Easily implented with pipeline cocoon cache. Personally I don't like this.
Joerg pointed out this can have inconsistencies in a form.

> per-user lists (cached for session duration, or with time expiration) -
and,

> per-request lists can be a (rarely used ;-)) option as well.

This one is what I need to use. I am implementing it right now. ;-)

Best Regards,

Antonio Gallardo.

Mime
View raw message