portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David G. Powers" <jetspeed-...@pssp.com>
Subject Re: Portlet Caching problem
Date Tue, 02 Apr 2002 03:00:54 GMT
Hash: SHA1

I acknowledge that most portlets should not be cached per session.

With a little thought it seems that caching would be futile for the 
WebPageProxyPortlet.  The only benefit would be in servicing a user 
obsessed with re-visiting the same links.

Oh well - It seemed like a good thought when I first wrote it...... 

What I really will need is a means to bypass the cache for all proxied 
requests.  That is already available via AbstractPortlet.isCachable().

On Monday 01 April 2002 06:57 pm, David Sean Taylor wrote:
> Please consider that RSS portlets do want to be shared across multiple
> users and instances.
> With anytype of content feed in general or shared resource, we don't
> want content per instance.
> Thus, the default mode of portlet caching *must* work exactly as it
> works now for backward compatibility.
> Not to mention having multitudes of un-necessary RSS feeds in memory.
> I've added several parameters recently to the registry to aid in
> caching:
> 	org.apache.jetspeed.om.registry.CachedParameter.isCachedOnName
> 	org.apache.jetspeed.om.registry.CachedParameter.isCachedOnValue
> 	org.apache.jetspeed.om.registry.ContentURL.isCachedOnURL()
> By default they are all set to true - so that we don't screw up shared
> resources (RSS).
> isCachedOnURL() is the only functional parameter right now. The other
> two will require refactoring of PortletConfig which looks a bit messy.
> If you want your portlet to be cached based on the psml-id + id, simply
> override the getHandle() in your portlet class or some base class. But
> please do not change AbstractPortlet's default behavior.
> > When any of this information changes, due to a re-load of the
> > registry, or a customization of the portlet on the page, we
> > must invalidate this object from the cache!
> Yes, when you reload a portlet from the registry, I would hope that it
> gets expired.
> Are you saying that it doesn't?
> > Two of the same portlets on the same page need to have
> > different Portal objects (these have different peids, at
> > least, and maybe different psml parameters).
> >
> > Two of the same portlets on different portal pages need to
> > have different Portal objects as well, for the same reason.
> >
> > A cached Portlet object could be reused for subsequent page
> > requests, and for page requests from other users viewing the
> > same page.  And only this - any other use of the portlet
> > would be a different portlet instance and need a different
> > Portlet object.
> >
> > So, a good handle for caching of one of these Portlet objects
> > would be the portlet's PEID, plus the portal page's unique
> > id.  The parameters don't matter, nor does the ancestry or
> > meta information, nor does the portlet class.
> >
> > I'll start making this change, if I hear a positive sanity
> > check from the developers.
> Please don't change AbstractPortlet.
> Why not change getHandle in VelocityPortlet or come up with a new class
> hierachy:
> SharedPortlet          InstancePortlet
> > Do we have anything from a portal page (or from the root
> > portlet set element in a page) that can be used for a unique
> > portal page id?  I need it for this (and other purposes!).
> > The file name is ok, but probably won't work for database
> Don't use the filename, it doesn't work with the DB version and is not
> normalized.
> The profiler, given a profile, can easily generate a standard, unique
> string identifying the page in a format such as:
>    /group/<group_name>   - no default group_name
>    /role/<role_name>     - no default role_name
>    /user/<user_name>     - defaults to the current user
>    /page/<page_name>     - defaults to /page/default (or what ever is
>                            configured in JR.p
>    /js_pane/<peid>       - Can not be used with /js_pane
>                            Defaults to the root element (pane or
> portlet)
>    /js_peid/<peid>       - Can not be used with /js_peid
>                            Defaults to the root element (pane or
> portlet)
>    /action/<action_name> - no default action_name
> I believ Paul was working on this for the JetspeedTemplateLink.
> > versions... Do we need to add a new PEID for this at the portal level?
> See
> Org.apache.jetspeed.om.profile.psml.PsmlPortlets is an IdentityElement,
> i.e. it has an ID.

- -- 
David G. Powers
Comment: Verify the authenticity of this message with the public key available at http://pssp.com/dgp_pk.asc


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