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 [EMAIL PROTECTED] 734-615-1419 --------------------------------------------------------------------- > > > -- > To unsubscribe, e-mail: <mailto:jetspeed-dev- > [EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:jetspeed-dev- > [EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
