An update, after dancing with the code last evening... The customizers break if I change the place the profile is stored, removing it from the user.temp into the rundata. I think the customizers expect the profile to have a scope wider than each individual request; a scope as large as the many requests of the customization session. This scope is fine for the customizers, but is wrong for the "user", as they may be doing other things. I'm spending today fixing the customizers, if I can figure them out ;).
The Profile does hold the PSMLDocument, so it's not just a light weight name thing, but the actual document as well. This is redundant with the caching which is in the PSML managers. The db psml manager has aggressive caching, even caching misses. This is good as it reduces the backend database access. There's a refresher thread running to make sure things in the cache are current (well, as current as the refresher which runs by default every 8 hours). Otherwise, the pages just fill up the cache, and memory. We could add some cache pruning based on LRU to the refresher thread, as Raphael suggests. I would like to see the Castor PSML manager fixed up for caching to have the same sort of thing as the db one, but I don't really use it much and not at all in production. Back to the customizers. I believe that they are doing things to the PSML document that is attached to the profile, and if we don't have this live past requests they don't work. First, I think this is bad, as they are messing with the "live" (and possibly cached) psml document - anyone else visiting the page will see changes in progress, I think, and there's no chance to "cancel" the edit. Also, if the user comes in with another window's request to another profile, it should mess up the customization process. And if another user starts customizing the same profile, this will also mess things up. What I want to do is let the customizers have a copy of the profile / psml document to work on. This copy would be associated with the request profile - i.e. the edit copy of the page would be stored in the state manager keyed by the page's profile and user session. This means that one user could edit any number of pages at a time from different windows, as each custommization state would be stored separately. It also means that any other users coming in would not see the changes until committed, and if the customizing user has another profile open in another window and requests come in from that, nothing is messed up. When they press the final "Apply" or "Save" or whatever, the copy would be put back into the PSML service, storing it on file / db and in the cache, and the edit copy and other state would be cleared. I'll look at what that might look like today. Comments? - Glenn > -----Original Message----- > From: Luta, Raphael (VUN) [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, September 24, 2002 4:06 AM > To: 'Jetspeed Developers List' > Subject: RE: Bug in JetspeedAccessController re: Profile > > > 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:jetspeed-dev-> [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]>
