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 :)
Thanks,
Carsten
Carsten Ziegeler Chief Architect Open Source Group, S&N AG
------------------------------------------------------------------
Cocoon Consulting, Training and Projects
------------------------------------------------------------------
mailto:[EMAIL PROTECTED] http://www.s-und-n.de
http://ziegeler.bei.t-online.de
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
