portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Scott T Weaver <scotts-jetspeed-l...@binary-designs.net>
Subject Re: [J2] Caching of entites and windows becoming an issue
Date Wed, 30 Jun 2004 17:55:47 GMT
On Wed, 2004-06-30 at 13:19, David Sean Taylor wrote:
> On Jun 30, 2004, at 9:30 AM, Scott T Weaver wrote:
> 
> > On Wed, 2004-06-30 at 11:52, David Sean Taylor wrote:
> >> On Jun 30, 2004, at 8:12 AM, Scott T Weaver wrote:
> >>
> >>> We are caching both PortletEntities and PortletWindows.
> >>>
> >>> This is becoming a serious issue with regards to re-deployment 
> >>> breaking
> >>> because of stale objects within misc. caches.
> >>>
> >> Could you explain this serious issue in a little more detail?
> >> I can't re-deploy here, because of a resource leak holding on to the
> >> jar file
> >>
> >> Its not clear what exactly the problem is from your description above,
> >> or if its related to the resource leak bug
> 
> How do you even get to the point where you can redeploy?
> For me, the war file is locked, see JS2-82, and redeploy is not possible

Which OS are you deploying on?  I have no trouble deleting the deploy
artifacts in WEB-INF/deploy.

> 
> 
> >> Is it because the portlet gets a new id, and the entity still points 
> >> to
> >> the old id?
> > Yep, that's it.  It would be nice if we could use unique name as an FK
> > instead of the PK.  Right now, when the entity goes to retrieve its
> > assoc. portlet def, after redeploy,  it fails as the PK has changed.
> >
> +1 on the unique name as the FK
> 
> 
> >> If the portlet knew about all of its entities, it could invalidate 
> >> them
> > I am invalidating entities, but because the cached window holds onto an
> > instance of the portlet entity BOTH caches need to be invalidated.  I
> > already added methods to the PortletEntityComponent to remove entities
> > from the cache just passing it a PortletApp.
> >
> > Actually, IMOHO, redeployment should not delete the associated
> > entities.  The reason being is that every time you redeploy an app all
> > of the user prefs get blown away.
> >
> yes, but you don't know if the portlet will exist again after redeploy
> The portlet could be removed from the deployment descriptor
> Does that mean the portal should remove the portlet and all entities?
> AFAIK the spec is not addressing this issue, so its up to us
> 
> When we undeploy now, the portlets are deleted
> If the portlets are deleted, normal ref integrity rules would require 
> also deleting the entities and psml refs
> However this has some bad side effects
> If you redeploy, you run undeploy, and lose all of your entities
> To get to the root of the problem, I think redeploy should be smart 
> enough to know which portlets are being deleted and which ones are 
> being replaced
> 
> >
> >>
> >>> 1. (Not so good approach) Expose both window and entity caches as
> >>> components so that they are accessible by any components that need to
> >>> manipulate the caches, like deployment.
> >>>
> >>> 2. (Better approach) Same as above, but use a single cache via a
> >>> caching
> >>> api like OSCache, http://www.opensymphony.com/oscache/
> >>>
> >>>
> >> Funny you mention that, I reviewed Open Symphony's oscache last night
> >> I was looking into putting a cache into the Profiler after looking at
> >> the Proxy Tools bug that Jeremy reported
> >>
> >> There is also
> >>
> >> http://jcache.sourceforge.net/
> > Don't know much about it.  Are there many other projects using it?
> >
> Its based on the JSR standard ... but I don't know of any projects 
> using it
> 
> >>
> >> and from Apache
> >>
> >> http://jakarta.apache.org/turbine/jcs/
> > TMK, JCS has never had a release and from what I have read on web,
> > people who were using JCS are moving to OSCache, for example, Hibernate
> > is moving from JCS to OSCache.
> >
> > As Hibernate has become the defacto OS O/R, OSCache appears to become
> > defacto OS caching api, AFAICT.
> >
> Yes it does seem to be the most mature cache, there is even a book on OS
> If you want to go with OSCache, Im +1 on it
> Just thought others might have opinions or experience and want to 
> comment
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
> 


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


Mime
View raw message