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
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 themI 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
Its based on the JSR standard ... but I don't know of any projects using it
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?
Yes it does seem to be the most mature cache, there is even a book on OS
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.
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]
