Geoff Howard wrote:
>Marcelo (and anyone else listening) -
>
><snip>
>
>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"?>
<INVALIDATION VERSION="WCS-1.0">
<OBJECT>
<ADVANCEDSELECTOR URIPREFIX="/cms/" URIEXP=".*">
<COOKIE NAME="PAGELAYOUT" VALUE="323456"/>
</ADVANCEDSELECTOR>
<ACTION REMOVALTTL="0"/>
</OBJECT>
</INVALIDATION>
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 - [EMAIL PROTECTED]
Do you Know DB Prism? Look @ http://www.plenix.com/dbprism/
More info?
Chapter 21 of the book "Professional XML Databases" (Wrox Press
http://www.wrox.com/)
Chapter 8 of the book "Oracle & Open Source" (O'Reilly
http://www.oreilly.com/catalog/oracleopen/)
-----------------------------------------------
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: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
