De : David Sean Taylor [mailto:[EMAIL PROTECTED]] > > If I remember correctly, when Glenn and I tested the WeakReferences, they > never kept anything in the cache.
Huh ? Strange... I'll check into that as soon as I find 30 minutes. > I agree the current implementation is flawed, but I don't think that putting > PSML in the session is the best solution. > It does help with caching, since if the page you request is the same as the > last request, then it successfully caches the resource. > But if you go to another page, then back, you will never receive the benefit > of caching. Agreed. My point was mainly to highlight what could be the possible consequences of changing where is stored the Profile, not prevent the change. Additionnally, for any Profile caching strategy you may consider, you need to remember that there's basically 2 main options for using Jetspeed: - anonymous: All users access the same sets of PSML over and over without having the possibility of customizing their own. In this scenario not caching documents have a terrible performance impact (imagine 10 simultaneous requests to the home page in a non-caching environment...) so you'll probably want aggressive caching. - user personalized: In this scenario most users would use their own PSML resource and you're pretty unlikely to get more than 1 request at a time to a single resource so you don't want to aggresive caching since this will complicate the customization process. The current structure (Session + weakreference) is a compromise design to balance both requirements. A more correct approach would be to implement an adaptative caching strategy in the PSML Manager and allow efficient caching while keeping the Profile bound to the request. > For this reason, and also for the reason that Im trying to make Jetspeed > sessions fully serializable (I know, good luck), I believe that the PSML > Managers will need to have more sophisticated caching algorithms for high > volume traffic. With the Castor implementation, which is generally low > volume, I would suggest dropping the WeakReferences and using References > until a better caching policy is in place. Hard references will only work if few PSML resources are accessed (ie few users) and more importantly will lock some memory that never get released. Maybe a better implementation would be to use a last accessed timestamp and a vulture thread that would remove from cache all entries that have not been accessed for more than X minutes. You end up with a cache that has 2 tunable parameters: - maximum number of entries - time to live in the cache I wonder if TurbineCache does not already let you use this kind of caching policy... What do you think ? -- Rapha�l Luta - [EMAIL PROTECTED] Technology and New Initiatives Vivendi Universal Networks - Paris -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
