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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
