cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Marcelo F. Ochoa" <>
Subject Re: Caching for database driven sites
Date Thu, 16 May 2002 12:58:20 GMT
Geoff Howard wrote:

>Marcelo (and anyone else listening) -
>We'll need (and so would others I think) something that de-couples this.
>For example, the database knows that the article table has been updated for
>record 323456 from the PAGELAYOUT table, but it doesn't (and shouldn't have
>to) know what cocoon cached items depend on it.  The trigger should be able
>to send the basic message: invalidate PAGELAYOUT 323456 and let cocoon keep
>track of (or figure out) what cached objects depend on that.  In our case it
>could be 1, but it could be 30.  We are porting an existing data
>architecture over to cocoon and the complexity really rules out totally
>restructuring the back end just to simplify the caching process.
>Just to be clear, we are only worrying about the basic generator caching
>here.  We know that cocoon can take care of figuring out its own
>dependencies for aggregates and includes which we are using as well.
 AFAIK Cocoon's caching algorithm uses the URL information for making 
the caching key (long value returned by generateKey() method), look at 
the sources for org.apache.cocoon.util.HashUtil and 
org.apache.cocoon.generation.FileGenerator as an example.
  Obviusly any Generator could implement your own generation key 
algorithm but I never seen a generator that base your key generation on 
the content off the XML message instead of the URL that identified it, 
obviusly for performance reason.
  The key that identified a composed message, using content aggregation 
for example, is composed using the string representation of the long key 
value plus the information that identified the generator involved, this 
string concatenation is used again with the HashUtil algorithm to get a 
new long value that identified all the components together, but none of 
the components are identified using his content.
  Cache gurus, correct me if I am wrong.

>Have I misunderstood your implementation?  Do you see a use for your ESI
>work in the above scenario?
  ESI protocol requires that the content is clearly pointed by the url + 
parameters + header attributes + cookies, but it permits to use 
wildcards into the url, then if your content is coherent with some 
cookie information you could use ESI for invalidating all the pages that 
content this cookie, in your example if you sent a Cookie 
PAGELAYOUT=323456 in every pages generated by your CMS, ESI will work 
ok. For example:

POST /dbprism/x-dbprism-cache-invalidate HTTP/1.0
Authorization: BASIC aW52YWxpZGF0b3I6aW52YWxpZGF0b3I=
Content-Length: 686

<?xml version="1.0"?>

  DBPrism's External Cache Implementation do not include bulk 
invalidation using wildcards, but I am working on it.

>Geoff Howard
  Best regards, Marcelo.

Marcelo F. Ochoa -
Do you Know DB Prism? Look @
More info?
Chapter 21 of the book "Professional XML Databases" (Wrox Press
Chapter 8 of the book "Oracle & Open Source" (O'Reilly
Lab. de Sistemas - Fac. de Cs. Exactas - UNICEN
Paraje Arroyo Seco - Campus Universitario
(7000) Tandil - Bs. AS. - Argentina
Te: +54-2293-444430 Fax: +54-2293-444431

To unsubscribe, e-mail:
For additional commands, email:

View raw message