Hi, with the new source resolving (from excalibur) we can implement a better caching mechanism (I mentioned this several times in the last weeks).
I'm just wondering, how the cache key should be generated. The current solution (Interface Cacheable) uses a long which is in 99,9% a hash value of the URI (with some additional information sometimes). This key is unique within the space of the component (e.g. file generator, xslt transformer etc). So the current implementation is nearly always the same: - Creating a string buffer - Appending all information - Hashing the string buffer The returned key (long value) is used by the caching algorithm to create a "big" key, representing the complete request, so if you have a pipeline with a generator and a transformer and a serializer, the caching algorithm gets the key of each component and builds a (guess what) string out of it! This string/key is then used to uniquely identify the request. Now, this approach works well, ehm, at least in most cases. From time to time there are complaints about key collisions. This is a potential danger as it *might* happen that two different strings produce the same hash value (as the long is limited in the possible values). So, what do you think if we use a appendKey(StringBuffer) method for the new cacheable interface instead? First the disadvantage: - The keys get longer (this could lead to collisions in the store...) The advantages: - No collision can occur - StringBuffer is used already by the caching algorithm - No need for hashing And now you Carsten --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
