Antwort: Re: Caching and key collision?

[Ku...@heinrich-partner.de]

I had a similar effect with an XSP getting data out of a database. It 
worked two times, but after that would not generate any new pages. New 
requests for data were answered by alternating between the first two 
generated pages. But there was no key collision, and the generate method 
for the XSP was called and had generated the correct data, but at the end 
the browser got the wrong page. Still investigating this, but feels like a 
bug.

Back to the key collision issue:

Say I configure a pipeline "XSP->Some XSL Transformation->HTML 
Serializer", and my XSP "test.xsp" uses hashing to generate the key out of 
a parameter "param" and its value. Let there be a key collision for two 
different parameter values "A" and "B", so requesting first 
"test.xsp?param=A" will generate a cache object and then requesting 
"test.xsp?param=B" will return this same object. Gerhard wrote that the 
pipeline pre- and appends other values, but won't these pre- and appended 
values (from the other pipeline elements?) be the same in both cases? 
Should cache keys probably be Strings to avoid this?

Regards,
Jochen





Michael Hartle <mh...@hartle-klug.com>
31.01.2002 02:24
Bitte antworten an cocoon-dev

 
        An:     cocoon-dev@xml.apache.org
        Kopie: 
        Thema:  Re: Caching and key collision?


giacomo wrote:

>On Wed, 30 Jan 2002, Gerhard Froehlich wrote:
>
>>>Thanks for the answers. JispFileSystemStore will do with the long file
>>>names. But what about accidental key collision? This still can happen.
>>>
>But chances are very low as IIRC from a developers point of view a key
>must be unique only withing a Component (FileGenerator,
>XSLTTransformer, etc.) and not over the hole system. The cache itself
>pre- or appends other values to form a system wide unique key for the
>cache entry.
>
I ocasionally have a problem that might have its origins in these very 
rare but possible accidental key collisions:

I am using an regexp-based pipeline which breaks down URI space into a 
set of parameters. These are passed to an XSP which generates dynamic 
SVG content which is solely based on these parameters. In order to 
minimize regeneration and utilize the cache, I added a generateKey() 
function to the XSP which, as already described, creates a key of type 
long on those parameters via hashing them. Now, in very rare occasions, 
in an sample web page showing many generated images (imgA, imgB, imgC), 
each located at another point in URI space (uriA, uriB, uriC), thus each 
one based on its set of parameters (prmA, prmB, prmC,...), one image, 
(imgB, loaded from uriB, thus based on prmB) suddenly looks like another 
one (shows imgA, loaded from uriB, should be based on prmB); when 
forcefully reloading the image from its URL, I seem to get a 
regeneration and the correct result.

It may be due to an unrelated mistake of mine that I haven't been able 
to detect yet, but accidental key collisions might explain such a 
sporadic behaviour.

Best regards,

Michael Hartle,
Hartle & Klug GbR


---------------------------------------------------------------------
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