cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Carsten Ziegeler" <>
Subject RE: [RT]: Calculating the cache key
Date Tue, 28 May 2002 12:54:25 GMT
Berin Loritsch wrote:

> > >
> > Yes, I thought about this over the weekend, too. Object as
> > the return value is the most flexible.
> >
> > But when using Object the caching algorithm is required to
> > build compound objects (arrays etc.) and cannot use simple
> > string operations
> > for building the compound key anymore. (Or the Object must
> > implement a reliable toString() method)
> I don't get the infatuation with the string method.  Keep in
> mind that the Object only has to worry about equals() and
> hashCode().  Both are fairly easy to implement. The default
> hashCode() for all Objects is the memory address the object
> occupies.  Now, using an Object to manage a compound key
> of straight ints or longs, can use lazy initialization.  Suppose
> the following class:
< <SNIP>
Yes, I was a wrong about hashCode etc. Of course you are right.
I changed the implementation to Serializable which I thought
is a good choice, because the Stores (e.g. the Jisp store)
require a Serializable key.

Unfortunately, the most used Store in Cocoon, the FilesystemStore
requires a toString() method! And this is the reason why the
old caching system used the toString() method and Strings.
But apart from that we don't need String operations here
at all and I changed everything to a more general code.

> > While building a compound object with for example an array is
> > a simple solution, I see currently a problem in storing this
> > into the cache. The cache can for example be implemented as a
> > hash table, so the compound key object must somehow implement
> > hashCode() and equals(). While equals() can be easily
> > implemented, I see no good solution for hashCode(). Do you
> > know a solution for this?
> Look above.
> There are two things you need to know about the default hashCode()
> for this to work:
> 1) Default hash values are the address of the object--meaning that
>    they are all aligned on a power of 2 ( typically every 4 or 8
>    bytes depending on 32 or 64 bit machines ).
> 2) Very regular hash values (like the default) will heavily weight
>    themselves to a particular buckets in the hash table (I found this
>    out creating the new BucketMap in Avalon collections).
> 3) You must ensure that the resultant hashCode is not an even number,
>    this will help ensure a more even distribution of hashvalues.  (this
>    is what the String hashCode tries to do).
> 4) The hashing algorithm must be quick--but it can be cashed for a
>    quick access.  That way if multiple tests on the hashCode occur,
>    you can save an expensive recalculation phase for each code.
You are a little bit behind this thread ;)

Volker and I discussed some of this already. The only thing which might need
some improvements is the implementation of the hashCode() methods in the
ComponentCacheKey and the PipelineCacheKey implementations :)


Carsten Ziegeler     Chief Architect     Open Source Group, S&N AG
             Cocoon Consulting, Training and Projects

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

View raw message