Glenn Golden wrote: >In fact, isn't the portlet cache totally wrong? If it finds a portlet >object in the cache, and uses this as the portlet object in the portlet set >used to process the request, and there's any sort of multiple portlet >instances going on (or, for that matter, any other user is viewing another >page that has the same portlet!), it will start reusing and modifying >meta/id on the object! I hope this is not the case... > Instantiating a portlet can be a very expensive operation, so Jetspeed tried to avoid it as much as possible.
The handle must be constructed in such a way that a unique handle guaranteed a unique instance (most like in a equals() method). For our purposes, handles must depend on all properties that make an instance different. Also, id should be inmutable, and meta also. There was a very interesting proposal in Cocoon one year ago about using a clever 64 bit hash as cache handle, to speed operations (concatenating strings to build the handle and using equals() to compare them are expensive operaitions). They also have CacheValidity Objects to enable that each portlet controls its caching in an extensible way: http://cvs.apache.org/viewcvs.cgi/xml-cocoon2/src/java/org/apache/cocoon/caching/CacheValidity.java?rev=1.5&content-type=text/vnd.viewcvs-markup The interface is pretty simple, but you can look to other implementations of Validities. > > >- Glenn > >-------------------------------------------- >Glenn R. Golden, Systems Research Programmer >University of Michigan School of Information >[EMAIL PROTECTED] 734-615-1419 >http://www-personal.si.umich.edu/~ggolden/ >-------------------------------------------- > > >-- >To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> >For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
