Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cocoon-dev@xml.apache.org
From: volker.schmitt@basf-it-services.com
To: cocoon-dev@xml.apache.org
Message-ID: <C1256BC7.0036315E.00@basf-ag-gw01.basf-ag.de>
Date: Tue, 28 May 2002 11:52:31 +0200
Subject: Antwort: RE: [RT]: Calculating the cache key
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline


Carsten Ziegeler wrote:
>>
>> Volker Schmitt wrote:
>> >
>> > Hi,
>> >
>> > the current Interface of CacheableProcessingComponent:
>> >
>> > <snip>
>> >
>> > why not using Object as a return value of "generateKey" ? I think
>> > this is more
>> > flexible and allows the implementation of Compound keys.
>> >
>> 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)
>>
>> 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?
>>

>I looked at the docs of the hash table and it seems that a hashCode
>computation is not so difficult: If two objects are equal they must
>have the same hash code. If the hash code differs, they are not equal.
>But if the hash code is the same, the objects must not necessarily
>the same.
>Ok, I give this a try and changed the type of the key from String to
>Serializable (and not to Object). Let's see if I can get this working
>today...

yes, HashTable/HashMap calls equal method to make sure that the search
key-Object is the same than the stored key in the HashMap. If we have a
Compound-Key you can implement the hashcode as a "sumary" or "xor" of the single
keys hashcode and implements the equal method as a compare of the corresponding
single keys, return true only if all keys are the same. The benefit is that we
do not need a String concat which generates additional Objects. I think it also
make sence to cache the hashcode of a key Object like it is done in the String
implementation (JDK > 1.2, Cocoon and JDK 1.2 will be much slower than using
1.3), this will significant improve the performance if hashcode is called
multible times.
What is the reason using Serializable instead of Object ?

>Regards
>Carsten

>Carsten Ziegeler     Chief Architect     Open Source Group, S&N AG
>------------------------------------------------------------------
>             Cocoon Consulting, Training and Projects
>------------------------------------------------------------------
>mailto:cziegeler@s-und-n.de                  http://www.s-und-n.de
>                    http://ziegeler.bei.t-online.de
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
>For additional commands, email: cocoon-dev-help@xml.apache.org


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