portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Glenn R. Golden" <ggol...@umich.edu>
Subject Re: A brief report on Jetspeed Portlet Caching
Date Mon, 13 May 2002 03:44:40 GMT
I stand (or more properly just now, sit) corrected: The 
JetspeedPortletCacheService *does* check the Cacheable's isCacheable() 
before letting it be cached.  JetspeedPortletFactoryService does not 
have to be "fixed" for this.

The bigger issue of caching and instance still remains...

- Glenn

On Sunday, May 12, 2002, at 10:27  PM, Glenn R. Golden wrote:

> Portlets are cached in the JetspeedPortletFactoryService.  The handle 
> is constructed by a static getHandle() method in the Portlet class 
> (currently in AbstractPortlet) which is given only a PortletConfig.  
> Since this is static, nothing about the Portlet except for the 
> PortletConfig may be used to form the cache handle.  The handle is 
> formed from the URL, if this is set, and the init parameters.  The 
> factory service adds a hash of the class name to the handle.
> Any portlet request checks what's in the cache, but only Portlets that 
> implement the Cacheable interface are placed into the cache.  Althought 
> Cacheable has a setting to enable / disable caching, this is currently 
> ignored by the Factory.  Since most all Portlets extends 
> AbstractPortlet, which is Cacheable, most all Portlets will be cached, 
> like it or not.  Based on a search of the code in CVS, only JspPortlet 
> attempts in it's init() to turn off caching; my belief is that this is 
> not being respected.
> This nixes any plans to extend AbstractPortlet to add a base Portlet 
> class that will provide the ID as part of the handle.  First, 
> AbstractPortlet already defines the static getHandle() method, and 
> second, the PortletConfig knows nothing about a portlet ID.
> Any Portlet code that needs to know its's own ID to properly 
> getContent() that is cached and operating in an environment where there 
> may be many placements of the Portlet on one or many Portal Pages, and 
> there may be multiple concurrent requests for pages (such as from 
> multiple users) WILL NOW FAIL.  The one cached Portlet + PortletConfig 
> will be retrieved for each request and MODIFIED to match the particular 
> details of the request's portlet instance.  Multiple threads will 
> modify the same object and there's no guarantee that the modifications 
> will be in place when they are needed.
> Another way to consider this is:  If a Portlet's PortletConfig might be 
> different in two different places, but the init parameters would be the 
> same (and the url, if appropriate), then THIS WILL FAIL.
> To fully solve this, we can turn off caching completely (and see slower 
> Jetspeed performance), turn it off for just those Portlets that need it 
> off (but to do this we need to operate on the code, since caching is 
> all or nothing currently), or include the Portlet's ID (and perhaps the 
> portal page's profile id) in the cache (this will result in more copies 
> of each portlet, but correct ones for those who care about instance.  
> The RSS portlet is one that might not like this as it does much work in 
> it's init and doesn't care much about portlet instance if the URLs 
> match).
> I'm just looking for comments right now, while I ponder exactly what to 
> do about caching.
> * * *
> Anybody want to vote to consider the caching broken right now because 
> it ignores the Cachable isCacheable() setting?  The 
> JetspeedPortletFactoryService() could easily be "fixed" to check this 
> before putting a Cacheable Portlet into the cache.  I'll put my +1 on 
> this.  Anybody know of any objections to this?

- Glenn

Glenn R. Golden    Systems Research Programmer
School of Information             University of Michigan
ggolden@umich.edu                            734-615-1419
> --
> To unsubscribe, e-mail:   <mailto:jetspeed-dev-
> unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: <mailto:jetspeed-dev-
> help@jakarta.apache.org>

To unsubscribe, e-mail:   <mailto:jetspeed-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:jetspeed-dev-help@jakarta.apache.org>

View raw message