xmlgraphics-fop-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Glen Mazza <gma...@apache.org>
Subject Re: Dynamic charts issues in batch PDF generation
Date Thu, 19 Jan 2006 21:11:56 GMT
Clay Leeds escribió:
> On Jan 19, 2006, at 10:30 AM, Glen Mazza wrote:
> 
>> Jeremias Maerki wrote:
>>
>>> Or you need to simply make sure that the URLs are unique. You can  use a
>>> dummy parameter in the URL to fake uniqueness:
>>> http://localhost/MyChartServlet?dummy=1234
>>
>>
>> Hmmm...my guess is that for any servlet-related problem for which a  
>> "dummy parameter to fake uniqueness" would solve it, that the  servlet 
>> itself can be rewritten to fix the problem instead.  (In  this case, 
>> have it coded to regenerate the image for every call,  with no dummy 
>> parameter needed.)  If I'm correct, I would refer the  questioner to 
>> the Sun Servlet forum for more assistance.
>>
>> Glen
> 
> 
> In my experience (mainly coming from a background where the user- agent 
> tends to be a web browser), if you call the same thing twice,  there are 
> a number of places where the object being served can be  'cached':
> - server
> - proxy
> - client
> 

Oh.  My interpretation of the problem was that a different PDF document 
*was* indeed being returned each time, but that the charts within the 
PDF document were incorrectly not being regenerated to account for the 
new data specific to each document.  If my assumption was the case, that 
would tend to rule out caching at the client or the proxy, because AFAIK 
they would just have a PDF document to cache (not inner parts, such a 
graphics within the PDF).

But if it is the case that the *same* PDF document is being sent each 
time to the browser, then yes, the caching may be at the client or 
proxy-level, and the URL modifying may be necessary.

Glen

> In some cases, the server itself also might have some sort of  'caching' 
> system as well, which is external to the server.
> 
> If someone is calling a cacheable resource, I've found it safest to  
> somehow modify the name (even slightly) to ensure there's no caching  
> involved. IMO, this alleviates the potential of cacheability (making  
> words up can be fun!).
> 
> Web Maestro Clay
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
> 
> 



---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org


Mime
View raw message