You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Vadim Gritsenko <vg...@hns.com> on 2001/07/05 15:50:10 UTC
Caching Issues; was: cvs commit: xml-cocoon2/src/org/apache/cocoon/transformation TraxTransformer.java
Carsten, Giacomo,
I don't know what to say... But let's look at an example.
Suppose you have an XML data and an XSLT to present it.
Obviously, you might have at least two variants to present this data,
and user chooses one he likes. From URL point of view, it might look like
http://host/cocoon/data?view=1 and http://host/cocoon/data?view=2.
With newly changes TraxTransformer, cache would work ONLY if your
site have ONE and ONLY ONE customer, or ALL customers have SAME preferences.
But this is not real situation, all people are different...
So, to make cache work, you FORCED to use
http://host/cocoon/data/view-1 and http://host/cocoon/data/view-2
which obviously means you have to rewrite your stylesheets and sitemap.
This was highly simplified example; in real app you would have 4-5 or more
parameters to control presentation. Take a look at least at slides example
in Cocoon2. Before, it was perfectly cacheable. And now - not.
I do think that newly introduced behaviour is might be desirable in some cases,
but I also want to have an opportunity to use previous one.
I do propose to introduce new parameter for TraxTransformer, something like
_useParametersValues. Other solution mught be to write derived transformer
which would do this. Let me know which way is preferred.
PS: I have built my site around content aggregation & caching,
I use computational stylesheets and I use cache extensively to
store computed results. So far, I managed to keep request time
under 300ms for requests which are with cache turned off might
easily take up to 30sec.
Thanks,
Vadim
> Giacomo Pati wrote:
>
> On Thu, 5 Jul 2001, Vadim Gritsenko wrote:
>
> > Giacomo,
> >
> > Previously it was possible to cache results for request
> > such as "page?param=value1" and "page?param=value2"
> > independently.
> >
> > This change would effectively disable cache for such
> > kind of requests. :(
> >
> > PS:
> > Previously key was generated from string like:
> > "systemid{param=value1}",
> > now it looks like:
> > "systemidparam"
>
> Well, I thought this is the right way to specify keys. Maybe Carsten can
> enlight us more. Isn't it true that the genKey method should use the
> NAMEs to build the key whereas the validate method takes the values into
> account.
>
Here is the light....
No, honestly, I think you are right:
The key identifies all input used by the transformer apart from the sax
stream,
so I think the key should contain also the parameter names (if they are used
by the transformer).
Then the validity objects validate the values of the parameters.
Carsten
</skip>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: AW: Caching Issues; was: cvs commit: xml-cocoon2/src/org/apache/cocoon/transformation
TraxTransformer.java
Posted by Donald Ball <ba...@webslingerZ.com>.
On Thu, 5 Jul 2001, Vadim Gritsenko wrote:
> Can you do just quick check on your JDK - how looks result of Map.toString()?
> My results:
> {a=b, x=y} under Win / VAge3.5, JDK 1.2.2-0
> {x=y, a=b} under Win / Sun JDK 1.3.0-C
> for the same code.
well, so much for that theory. i filled a map with 1000 pairs and called
toString(), it printed them all. blackdown-jdk-1.3.0fcs
> > perhaps we should instead modify giacomo's patch to add the map values to
> > the hash string?
>
> It's good idea if JDK implementations differs.
i still think we might should do this anyway, since the javadocs don't
_say_ that you won't get something like "@A95834java.util.HashMap"...
- donald
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: AW: Caching Issues; was: cvs commit: xml-cocoon2/src/org/apache/cocoon/transformation TraxTransformer.java
Posted by Vadim Gritsenko <vg...@hns.com>.
> -----Original Message-----
> From: Donald Ball [mailto:balld@webslingerZ.com]
> Sent: Thursday, July 05, 2001 14:02
> To: cocoon-dev@xml.apache.org
> Subject: Re: AW: Caching Issues; was: cvs commit: xml-cocoon2/src/org/apache/cocoon/transformation
> TraxTransformer.java
>
>
> On Thu, 5 Jul 2001, Carsten Ziegeler wrote:
>
> > Now I understand your problem. Quick thinking, I would say that
> > the generated key not only contains the parameter names but
> > the parameter values as well. I think this is ok, as you could
> > say that the file name of the xsl file is a paramter named
> > file with the value of the real file name.
> >
> > Then all requests for that pipeline with exactly the same
> > parameter set will lead to the same key and to the same
> > cached content.
> >
> > I assume this is the way, I should work. Right?
>
> maybe it _should_, but my experience was to the contrary. after adding a
> patch to add cookies to the values map, even when cookies varied, i still
> got the cached output from the stylesheet.
It should always return cached result, but different for different parameter values
(cookies in your case). It should cache results for every variation of input parameters' values.
> looking through the api docs,
> it doesn't seem that Map.toString() is guaranteed to produce a string
> containing all of the names and values in the map. maybe it does with some
> jdk's and doesn't with others?
Can you do just quick check on your JDK - how looks result of Map.toString()?
My results:
{a=b, x=y} under Win / VAge3.5, JDK 1.2.2-0
{x=y, a=b} under Win / Sun JDK 1.3.0-C
for the same code.
>
> perhaps we should instead modify giacomo's patch to add the map values to
> the hash string?
It's good idea if JDK implementations differs.
>
> - donald
>
Vadim
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: AW: Caching Issues; was: cvs commit: xml-cocoon2/src/org/apache/cocoon/transformation
TraxTransformer.java
Posted by Donald Ball <ba...@webslingerZ.com>.
On Thu, 5 Jul 2001, Carsten Ziegeler wrote:
> Now I understand your problem. Quick thinking, I would say that
> the generated key not only contains the parameter names but
> the parameter values as well. I think this is ok, as you could
> say that the file name of the xsl file is a paramter named
> file with the value of the real file name.
>
> Then all requests for that pipeline with exactly the same
> parameter set will lead to the same key and to the same
> cached content.
>
> I assume this is the way, I should work. Right?
maybe it _should_, but my experience was to the contrary. after adding a
patch to add cookies to the values map, even when cookies varied, i still
got the cached output from the stylesheet. looking through the api docs,
it doesn't seem that Map.toString() is guaranteed to produce a string
containing all of the names and values in the map. maybe it does with some
jdk's and doesn't with others?
perhaps we should instead modify giacomo's patch to add the map values to
the hash string?
- donald
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: Caching Issues; was: cvs commit: xml-cocoon2/src/org/apache/cocoon/transformation TraxTransformer.java
Posted by Vadim Gritsenko <vg...@hns.com>.
Hi Carsten,
I think you got it right. Shall we revert generateKey method to use map.toString() back?
Or add some kind of parameter ("to cache or not to cache") to transformer?
Vadim
> -----Original Message-----
> From: Carsten Ziegeler [mailto:cziegeler@sundn.de]
> Sent: Thursday, July 05, 2001 11:14
> To: cocoon-dev@xml.apache.org
> Subject: AW: Caching Issues; was: cvs commit: xml-cocoon2/src/org/apache/cocoon/transformation TraxTransformer.java
>
>
> Hi Vadim,
>
> sorry I am little bit confused today by the heat in this office.
>
> Now I understand your problem. Quick thinking, I would say that
> the generated key not only contains the parameter names but
> the parameter values as well. I think this is ok, as you could
> say that the file name of the xsl file is a paramter named
> file with the value of the real file name.
>
> Then all requests for that pipeline with exactly the same
> parameter set will lead to the same key and to the same
> cached content.
>
> I assume this is the way, I should work. Right?
>
>
> Carsten
>
> Open Source Group sunShine - b:Integrated
> ================================================================
> Carsten Ziegeler, S&N AG, Klingenderstrasse 5, D-33100 Paderborn
> www.sundn.de mailto: cziegeler@sundn.de
> ================================================================
>
>
> > Vadim Gritsenko wrote:
> >
> > Carsten, Giacomo,
> >
> > I don't know what to say... But let's look at an example.
> > Suppose you have an XML data and an XSLT to present it.
> > Obviously, you might have at least two variants to present this data,
> > and user chooses one he likes. From URL point of view, it might look like
> > http://host/cocoon/data?view=1 and http://host/cocoon/data?view=2.
> > With newly changes TraxTransformer, cache would work ONLY if your
> > site have ONE and ONLY ONE customer, or ALL customers have SAME
> > preferences.
> > But this is not real situation, all people are different...
> >
> > So, to make cache work, you FORCED to use
> > http://host/cocoon/data/view-1 and http://host/cocoon/data/view-2
> > which obviously means you have to rewrite your stylesheets and sitemap.
> >
> > This was highly simplified example; in real app you would have 4-5 or more
> > parameters to control presentation. Take a look at least at slides example
> > in Cocoon2. Before, it was perfectly cacheable. And now - not.
> >
> > I do think that newly introduced behaviour is might be desirable
> > in some cases,
> > but I also want to have an opportunity to use previous one.
> > I do propose to introduce new parameter for TraxTransformer,
> > something like
> > _useParametersValues. Other solution mught be to write derived
> > transformer
> > which would do this. Let me know which way is preferred.
> >
> > PS: I have built my site around content aggregation & caching,
> > I use computational stylesheets and I use cache extensively to
> > store computed results. So far, I managed to keep request time
> > under 300ms for requests which are with cache turned off might
> > easily take up to 30sec.
> >
> > Thanks,
> > Vadim
> >
> >
> > > Giacomo Pati wrote:
> > >
> > > On Thu, 5 Jul 2001, Vadim Gritsenko wrote:
> > >
> > > > Giacomo,
> > > >
> > > > Previously it was possible to cache results for request
> > > > such as "page?param=value1" and "page?param=value2"
> > > > independently.
> > > >
> > > > This change would effectively disable cache for such
> > > > kind of requests. :(
> > > >
> > > > PS:
> > > > Previously key was generated from string like:
> > > > "systemid{param=value1}",
> > > > now it looks like:
> > > > "systemidparam"
> > >
> > > Well, I thought this is the right way to specify keys. Maybe Carsten can
> > > enlight us more. Isn't it true that the genKey method should use the
> > > NAMEs to build the key whereas the validate method takes the values into
> > > account.
> > >
> > Here is the light....
> >
> > No, honestly, I think you are right:
> >
> > The key identifies all input used by the transformer apart from the sax
> > stream,
> > so I think the key should contain also the parameter names (if
> > they are used
> > by the transformer).
> > Then the validity objects validate the values of the parameters.
> >
> > Carsten
> >
> > </skip>
> >
> > ---------------------------------------------------------------------
> > 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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
AW: Caching Issues; was: cvs commit: xml-cocoon2/src/org/apache/cocoon/transformation TraxTransformer.java
Posted by Carsten Ziegeler <cz...@sundn.de>.
Hi Vadim,
sorry I am little bit confused today by the heat in this office.
Now I understand your problem. Quick thinking, I would say that
the generated key not only contains the parameter names but
the parameter values as well. I think this is ok, as you could
say that the file name of the xsl file is a paramter named
file with the value of the real file name.
Then all requests for that pipeline with exactly the same
parameter set will lead to the same key and to the same
cached content.
I assume this is the way, I should work. Right?
Carsten
Open Source Group sunShine - b:Integrated
================================================================
Carsten Ziegeler, S&N AG, Klingenderstrasse 5, D-33100 Paderborn
www.sundn.de mailto: cziegeler@sundn.de
================================================================
> Vadim Gritsenko wrote:
>
> Carsten, Giacomo,
>
> I don't know what to say... But let's look at an example.
> Suppose you have an XML data and an XSLT to present it.
> Obviously, you might have at least two variants to present this data,
> and user chooses one he likes. From URL point of view, it might look like
> http://host/cocoon/data?view=1 and http://host/cocoon/data?view=2.
> With newly changes TraxTransformer, cache would work ONLY if your
> site have ONE and ONLY ONE customer, or ALL customers have SAME
> preferences.
> But this is not real situation, all people are different...
>
> So, to make cache work, you FORCED to use
> http://host/cocoon/data/view-1 and http://host/cocoon/data/view-2
> which obviously means you have to rewrite your stylesheets and sitemap.
>
> This was highly simplified example; in real app you would have 4-5 or more
> parameters to control presentation. Take a look at least at slides example
> in Cocoon2. Before, it was perfectly cacheable. And now - not.
>
> I do think that newly introduced behaviour is might be desirable
> in some cases,
> but I also want to have an opportunity to use previous one.
> I do propose to introduce new parameter for TraxTransformer,
> something like
> _useParametersValues. Other solution mught be to write derived
> transformer
> which would do this. Let me know which way is preferred.
>
> PS: I have built my site around content aggregation & caching,
> I use computational stylesheets and I use cache extensively to
> store computed results. So far, I managed to keep request time
> under 300ms for requests which are with cache turned off might
> easily take up to 30sec.
>
> Thanks,
> Vadim
>
>
> > Giacomo Pati wrote:
> >
> > On Thu, 5 Jul 2001, Vadim Gritsenko wrote:
> >
> > > Giacomo,
> > >
> > > Previously it was possible to cache results for request
> > > such as "page?param=value1" and "page?param=value2"
> > > independently.
> > >
> > > This change would effectively disable cache for such
> > > kind of requests. :(
> > >
> > > PS:
> > > Previously key was generated from string like:
> > > "systemid{param=value1}",
> > > now it looks like:
> > > "systemidparam"
> >
> > Well, I thought this is the right way to specify keys. Maybe Carsten can
> > enlight us more. Isn't it true that the genKey method should use the
> > NAMEs to build the key whereas the validate method takes the values into
> > account.
> >
> Here is the light....
>
> No, honestly, I think you are right:
>
> The key identifies all input used by the transformer apart from the sax
> stream,
> so I think the key should contain also the parameter names (if
> they are used
> by the transformer).
> Then the validity objects validate the values of the parameters.
>
> Carsten
>
> </skip>
>
> ---------------------------------------------------------------------
> 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
RE: Caching Issues; was: cvs commit: xml-cocoon2/src/org/apache/cocoon/transformation TraxTransformer.java
Posted by Vadim Gritsenko <vg...@yahoo.com>.
Done.
Vadim
> -----Original Message-----
> From: Carsten Ziegeler [mailto:cziegeler@sundn.de]
> Sent: Friday, July 06, 2001 1:57
> To: cocoon-dev@xml.apache.org
> Subject: AW: Caching Issues; was: cvs commit: xml-cocoon2/src/org/apache/cocoon/transformation TraxTransformer.java
>
>
> Regarding this issue I think we should simply add the handling of
> the parameter values to Giacomo's patch.
>
> Carsten
>
> > -----Ursprungliche Nachricht-----
> > Von: Vadim Gritsenko [mailto:vgritsenko@hns.com]
> > Gesendet: Donnerstag, 5. Juli 2001 23:13
> > An: cocoon-dev@xml.apache.org
> > Betreff: RE: Caching Issues; was: cvs commit:
> > xml-cocoon2/src/org/apache/cocoon/transformation TraxTransformer.java
> >
> >
> > > -----Original Message-----
> > > From: Donald Ball [mailto:balld@webslingerZ.com]
> > > Sent: Thursday, July 05, 2001 14:16
> > > To: Cocoon Developers
> > > Subject: Re: Caching Issues; was: cvs commit:
> > xml-cocoon2/src/org/apache/cocoon/transformation TraxTransformer.java
> > >
> > >
> > > On Thu, 5 Jul 2001, Vadim Gritsenko wrote:
> > >
> > > > I do think that newly introduced behaviour is might be desirable in
> > > > some cases, but I also want to have an opportunity to use previous
> > > > one. I do propose to introduce new parameter for TraxTransformer,
> > > > something like _useParametersValues. Other solution mught be to write
> > > > derived transformer which would do this. Let me know which way is
> > > > preferred.
> > >
> > > why would it ever be desirable to use just the parameter name, but not
> > > its value, in the cache key?
> >
> > You are right... Makes no sence. I was thinking about parameter
> > to disable caching -
> > it might be useful if you know beforehand that this
> > transformation would take much less
> > time comparing to amount of RAM required to cache results :)
> > Usually this is the last transformation in the pipeline.
> >
> > Vadim
> >
> > >
> > > - donald
> > >
> > >
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
AW: Caching Issues; was: cvs commit: xml-cocoon2/src/org/apache/cocoon/transformation TraxTransformer.java
Posted by Carsten Ziegeler <cz...@sundn.de>.
Regarding this issue I think we should simply add the handling of
the parameter values to Giacomo's patch.
Carsten
> -----Ursprungliche Nachricht-----
> Von: Vadim Gritsenko [mailto:vgritsenko@hns.com]
> Gesendet: Donnerstag, 5. Juli 2001 23:13
> An: cocoon-dev@xml.apache.org
> Betreff: RE: Caching Issues; was: cvs commit:
> xml-cocoon2/src/org/apache/cocoon/transformation TraxTransformer.java
>
>
> > -----Original Message-----
> > From: Donald Ball [mailto:balld@webslingerZ.com]
> > Sent: Thursday, July 05, 2001 14:16
> > To: Cocoon Developers
> > Subject: Re: Caching Issues; was: cvs commit:
> xml-cocoon2/src/org/apache/cocoon/transformation TraxTransformer.java
> >
> >
> > On Thu, 5 Jul 2001, Vadim Gritsenko wrote:
> >
> > > I do think that newly introduced behaviour is might be desirable in
> > > some cases, but I also want to have an opportunity to use previous
> > > one. I do propose to introduce new parameter for TraxTransformer,
> > > something like _useParametersValues. Other solution mught be to write
> > > derived transformer which would do this. Let me know which way is
> > > preferred.
> >
> > why would it ever be desirable to use just the parameter name, but not
> > its value, in the cache key?
>
> You are right... Makes no sence. I was thinking about parameter
> to disable caching -
> it might be useful if you know beforehand that this
> transformation would take much less
> time comparing to amount of RAM required to cache results :)
> Usually this is the last transformation in the pipeline.
>
> Vadim
>
> >
> > - donald
> >
> >
> > ---------------------------------------------------------------------
> > 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: Caching Issues; was: cvs commit: xml-cocoon2/src/org/apache/cocoon/transformation TraxTransformer.java
Posted by Vadim Gritsenko <vg...@hns.com>.
> -----Original Message-----
> From: Donald Ball [mailto:balld@webslingerZ.com]
> Sent: Thursday, July 05, 2001 14:16
> To: Cocoon Developers
> Subject: Re: Caching Issues; was: cvs commit: xml-cocoon2/src/org/apache/cocoon/transformation TraxTransformer.java
>
>
> On Thu, 5 Jul 2001, Vadim Gritsenko wrote:
>
> > I do think that newly introduced behaviour is might be desirable in
> > some cases, but I also want to have an opportunity to use previous
> > one. I do propose to introduce new parameter for TraxTransformer,
> > something like _useParametersValues. Other solution mught be to write
> > derived transformer which would do this. Let me know which way is
> > preferred.
>
> why would it ever be desirable to use just the parameter name, but not
> its value, in the cache key?
You are right... Makes no sence. I was thinking about parameter to disable caching -
it might be useful if you know beforehand that this transformation would take much less
time comparing to amount of RAM required to cache results :)
Usually this is the last transformation in the pipeline.
Vadim
>
> - donald
>
>
> ---------------------------------------------------------------------
> 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
Re: Caching Issues; was: cvs commit: xml-cocoon2/src/org/apache/cocoon/transformation
TraxTransformer.java
Posted by Donald Ball <ba...@webslingerZ.com>.
On Thu, 5 Jul 2001, Vadim Gritsenko wrote:
> I do think that newly introduced behaviour is might be desirable in
> some cases, but I also want to have an opportunity to use previous
> one. I do propose to introduce new parameter for TraxTransformer,
> something like _useParametersValues. Other solution mught be to write
> derived transformer which would do this. Let me know which way is
> preferred.
why would it ever be desirable to use just the parameter name, but not
its value, in the cache key?
- donald
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org