cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Antti Koivunen <anryo...@users.sourceforge.net>
Subject Re: Caching and key collision?
Date Wed, 30 Jan 2002 07:29:08 GMT
Hi,

Gerhard Froehlich wrote:

> Hi,
> 
> 
>>From: Kuhnle@heinrich-partner.de [mailto:Kuhnle@heinrich-partner.de]
>>
>>Hi, 
>>
>>Thanks for the answers. JispFileSystemStore will do with the long file 
>>names. But what about accidental key collision? This still can happen.
>>
>>----
>>I noticed caching is done by generating a key with generateKey. This 
>>returns a long, which is commonly generated through hashing. The 
>>documentation says "This key must be unique inside the space of this 
>>component", which hashing does not guarantee. Won't this lead the cache to 
>>confusing two different cacheable objects (files/server pages/etc.) which 
>>accidently have the same hash value? This sure is an unlikely event, but 
>>ist still can happen.
>>
> 
> I solved this problem once in a project using:
>   java.rmi.server.UID
> 
> It generates a unique number! What do you think!

I'm sure it works fine in many cases, but it might in a way violate the 
idea of generateKey(), and the IDs (although always unique) won't 
persist between JVM executions unless specific DataInputs/Outputs are used.

As a bigger design pattern, I often see it as better SoC to let the 
component focus on the functionality, and whoever is managing the 
caching be responsible of assigning the keys. However, the situation is 
different for certain components, such as Generators that operate in 
their own "entity space". In this case it may be better SoC to require 
generateKey(), as it certainly shouldn't concern the sitemap and 
pipelines. AUI, this does however imply that the user should know how 
the generateKey() method is implemented for each Generator. In practice, 
though, this doesn't usually cause problems.

Got a bit sidetracked there, sorry :) Any thoughts?

-- 
Antti Koivunen | "Anrie" [un-ree] <anryoshi@users.sf.net>
---------------------------------------------------------
The song of life might not be a simple one,
but there's plenty of room for improvisation.
---------------------------------------------------------



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


Mime
View raw message