Hi, Gerhard Froehlich wrote:
> Hi, > > >>From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] >> >>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] <[EMAIL PROTECTED]> --------------------------------------------------------- The song of life might not be a simple one, but there's plenty of room for improvisation. --------------------------------------------------------- --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
