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 A brief report on Jetspeed Portlet Caching
Date Mon, 13 May 2002 02:27:18 GMT
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>


Mime
View raw message