Return-Path: Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm Delivered-To: mailing list cocoon-dev@xml.apache.org Received: (qmail 84266 invoked from network); 26 Jan 2001 23:02:19 -0000 Received: from f87.law4.hotmail.com (HELO hotmail.com) (216.33.149.87) by h31.sny.collab.net with SMTP; 26 Jan 2001 23:02:19 -0000 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 26 Jan 2001 15:02:00 -0800 Received: from 148.88.0.10 by lw4fd.law4.hotmail.msn.com with HTTP; Fri, 26 Jan 2001 23:01:59 GMT X-Originating-IP: [148.88.0.10] From: "Robin Green" To: cocoon-dev@xml.apache.org Subject: Re: AW: [C2]: Proposal for caching: Smarter Monitor Placement Date: Fri, 26 Jan 2001 23:01:59 -0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 26 Jan 2001 23:02:00.0095 (UTC) FILETIME=[FD2BE2F0:01C087EB] X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N "Tagunov Anthony" wrote: >Hello, gentelmen! > >To contribute to this caching issues discussion, >plz let me point out something that I consider was >a bottleneck for C1: > >The monitors were embedded into processors and it caused the >following difficulties: > >1) When the page was actually removed from cahce, the dependency > in the processor monitors still remained there, so >1.1) suppose request "../a.xml?b=18" was found to depend on "b.xsl" > then, a.xml was rewritten in a way that this dependency was >removed. > Still, the "b.xsl" remained in the XSLTProcessor's monitor table >denoting > that "../a.xml?b=18" depended on "b.xsl" and when someone chainged > "b.xsl" then the cache for "../a.xml?b=18" (provided that >"../a.xml?b=18" > was still processed by the XSLTProcessor) was considered invalid. > >1.2) suppose "../a.xml?b=.." gets called with a VERY VARING NUMBER > of parameter (I considered using it for a web resource directory, > wich currently has thousads (and large sousands of sections, > and the appearance of page may be user dependent). Then > The monitors may potentially get to contain PLETHORA of > useless dependencies for pages that have already been > cleaned from cache and thus eat up memory. > >So, what I think appropriate, is to > >=========================================================== >Proposal#1) > keep information needed by a > processor (translator, transformet in terms of C2 ?) to determine > weather it's output has chainged TOGETHER with the cached > page. > Then, when the page (the cached output) gets cleaned, > then the dependencies information would vanish together with it. +1. I'm trying to do something similar with C1. Of course in C2 it's more complicated because there might be more than one output being cached, because of caching at different stages. _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.