cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Carsten Ziegeler" <cziege...@s-und-n.de>
Subject [RT]: Calculating the cache key
Date Tue, 21 May 2002 10:32:31 GMT
Hi,

with the new source resolving (from excalibur) we can implement
a better caching mechanism (I mentioned this several times
in the last weeks).

I'm just wondering, how the cache key should be generated.

The current solution (Interface Cacheable) uses a long which is
in 99,9% a hash value of the URI (with some additional information
sometimes). This key is unique within the space of the component 
(e.g. file generator, xslt transformer etc).
So the current implementation is nearly always the same:
- Creating a string buffer
- Appending all information
- Hashing the string buffer

The returned key (long value) is used by the caching algorithm
to create a "big" key, representing the complete request, so
if you have a pipeline with a generator and a transformer
and a serializer, the caching algorithm gets the key of each
component and builds a (guess what) string out of it!
This string/key is then used to uniquely identify the request.

Now, this approach works well, ehm, at least in most cases. From
time to time there are complaints about key collisions. This is
a potential danger as it *might* happen that two different strings
produce the same hash value (as the long is limited in the possible
values).

So, what do you think if we use a appendKey(StringBuffer) method
for the new cacheable interface instead?
First the disadvantage:
- The keys get longer (this could lead to collisions in the store...)

The advantages:
- No collision can occur
- StringBuffer is used already by the caching algorithm
- No need for hashing

And now you

Carsten

---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message