> Yves Zoundi wrote:
> > THE SOLUTION
> > The issue with the i18ntransformer is that generated cache
> keys are not
> > unique. A simple solution which might not be the best is:
> ...
> > public class I18nTransformerFix extends I18nTransformer {
> > public Serializable getKey() {
> > StringBuffer buff = new StringBuffer();
> > buff.append("" + System.currentTimeMillis());
> > buff.append("_");
> > buff.append(super.getKey());
> > return buff.toString();
> > }
> > }
>
> Whoa... using the current time in the cache key pretty much
> guarantees
> that two calls of getKey() will never return the same value, and
> therefore you'll never get a cache hit. This renders caching
> completely
> useless, it's just as if the I18nTransformer were not
> cacheable at all!
Indeed! You must neven ever allow things like a timestamp ending up in your
cache key. If you have
<map:transform src="somexsl.xsl">
<map:parameter name="time" value="{date:yyyyMMddHHmmss}"/>
and it is in a caching pipeline, your cache gets stuffed with unreachable keys.
Also, be aware of user specific info ending up in cache keys: If you have in
your xsl a parameter like
<map:parameter name="refurl" value="{header:referer}"/>
then, depending on from which page a visitor came, a cachekey is
constructed...bad!!
It is not very basic, but during building sites, and certainly when they are
havy load sites, I keep track of cachekeys, and how they look. Also the number
of cachekeys generated for each new page is quite important: when I browse
through an archive through pages, and every hit results in for example 8 new
pipeline cachekeys (while most of the page did not change), then your cache is
quite inefficient
As Jason suggested, the examples work fine, so probably something is missing at
what you have. There is only one quite annoying drawback of the
I18nTransformer, and that is that it return a NOPValidity, so changing my
catalogues won't be picked up (though shouldn't be to hard to fix)
Regards Ard
>
> I still don't see why you're having problems to begin with.
> As long as
> the locale is correctly used to build the cache key
> everything should be
> fine and dandy. If something's going wrong with that then I think a
> real fix needs to be found rather than adding extra junk to
> the cache key.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
