portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Sean Taylor <david.sean.tay...@bbc.co.uk>
Subject RE: Bug in JetspeedAccessController re: Profile
Date Mon, 23 Sep 2002 22:18:05 GMT
If I remember correctly, when Glenn and I tested the WeakReferences, they
never kept anything in the cache.
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.
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.

> -----Original Message-----
> From: Luta, Raphael (VUN) [mailto:Raphael.Luta@groupvu.Com] 
> Sent: 23 September 2002 18:30
> To: 'Jetspeed Developers List'
> Subject: RE: Bug in JetspeedAccessController re: Profile
> 
> 
> I'm not so sure about this is the current implementation.
> 
> CastorPsmlManager cache work with a WeakReference to the 
> Document so the 
> reference will only stay valid if another reference is used 
> at any time within the system.
> 
> Basically this handles very well the 'anonymous' case where 
> many people 
> may access the same PSML resource and thus you can share the 
> same backend document instance in many requests but for a 
> "logged in" user scenario, you risk dealing with the 
> following situation:
> 
> User first request
> PSMLManager loads Document resource
> RunData stores Document resource
> RunData release Document resource
> User second request
> PSMLManager finds expired WeakReference and loads Document
> ...
> 
> On the other hand, if you keep hard references in your 
> PSMLManager, your cache will grow with the server uptime and 
> number of users since documents would stay loaded even if the 
> user sessions are closed and you would need to implement a 
> cache management policy to expire stale entries.
> 
> > -----Message d'origine-----
> > De : David Sean Taylor [mailto:david.sean.taylor@bbc.co.uk]
> > Envoyé : lundi 23 septembre 2002 19:18
> > À : 'Jetspeed Developers List'
> > Objet : RE: Bug in JetspeedAccessController re: Profile
> > 
> > 
> > The PSML Manager caches the PSML document.
> > If you map to the same psml document, then it shouldn't be 
> > much of a hit
> > 
> > It's the job of the PSML Manager to handle caching of the 
> heavyweight 
> > PSMLDocument The profile locator is lightweight
> > 
> > > -----Original Message-----
> > > From: Luta, Raphael (VUN) [mailto:Raphael.Luta@groupvu.Com]
> > > Sent: 23 September 2002 18:10
> > > To: 'Jetspeed Developers List'
> > > Subject: RE: Bug in JetspeedAccessController re: Profile
> > > 
> > > 
> > > Mmmm... if you load/unload the profile per request you may
> > > end up with a 
> > > significant performance hit, especially in the Castor XML 
> > > file model: reading the file, parsing the XML file and 
> > > creating the profile is *not* a lightweight operation so you 
> > > probably don't want do it every request.
> > > 
> > > Storing the Profile in the session was a way to have a better
> > > persistence without handling a complex pool system but I 
> > > agree it would more correct to store the Profile in the 
> > > RunData object and manage a Pool either within the
> > > PSMLManager(s) or the Profiler implementations.
> > > 
> > > > -----Message d'origine-----
> > > > De : David Sean Taylor [mailto:david.sean.taylor@bbc.co.uk]
> > > > Envoyé : lundi 23 septembre 2002 19:05
> > > > À : 'Jetspeed Developers List'
> > > > Cc : 'Ruchir Gatha'
> > > > Objet : RE: Bug in JetspeedAccessController re: Profile
> > > > 
> > > > 
> > > > You will get a big +1 from me, that is as long as you 
> don't break 
> > > > anything
> > > > ;)
> > > > 
> > > > We are just looking into making all objects 
> serializable that are 
> > > > put in the session.
> > > > And I was just hoping we could remove the profile object, 
> > > > since its nested
> > > > with other objects. 
> > > > 
> > > > Why not simply use the DefaultJetspeedRunData's profile 
> in the get 
> > > > and set methods
> > > > 
> > > >     private Profile profile = null;
> > > > 
> > > > A profile is only good per request, I agree the current code is 
> > > > wrong and should be changed to use the data member and not 
> > > > get/setTemp
> > > > 
> > > > 
> > > > > -----Original Message-----
> > > > > From: Glenn Golden [mailto:ggolden@umich.edu]
> > > > > Sent: 23 September 2002 18:04
> > > > > To: 'Jetspeed-Dev (jetspeed-dev@jakarta.apache.org)'
> > > > > Subject: Bug in JetspeedAccessController re: Profile
> > > > > 
> > > > > 
> > > > > The JetspeedAccessController sets the profile based on the 
> > > > > current request into the data's user's setProfile() (which is 
> > > > > stored in the user's temp area).
> > > > > 
> > > > > This is wrong.  The scope in which the data is stored 
> (session - 
> > > > > user) is way to broad for the scope in which the data 
> is valid 
> > > > > (session - user - request).
> > > > > 
> > > > > If two requests come in from the same user, and are worked on 
> > > > > overlapped, and are from two different profiles, the 
> second to 
> > > > > start will re-set the profile that the first set, and 
> they will 
> > > > > both get the second's profile if either call the data's 
> > > > > getProfile().
> > > > > 
> > > > > My Jetspeed app. is actually running into this occasionally!
> > > > > 
> > > > > I will fix this.  Either by putting in this:
> > > > > 
> > > > > Profile.getProfile(this)
> > > > > 
> > > > > In DefaultJetspeedRunData's getProfile() and nothing in the 
> > > > > setProfile(), effectively not caching the profile,
> > > > > 
> > > > > or cache the profile for the current thread using a hashtable 
> > > > > based on thread somewhere where the rundata can find it
> > > for set/get.
> > > > > 
> > > > > Any other ideas?
> > > > > 
> > > > > Comments?  Thanks!
> > > > > 
> > > > > - Glenn
> > > > >  
> > > > > --------------------------------------------
> > > > > Glenn R. Golden, Systems Research Programmer
> > > > > University of Michigan School of Information
> > > > > ggolden@umich.edu               734-615-1419
> > > > > --------------------------------------------
> > > > > 
> > > > > 
> > > > > --
> > > > > To unsubscribe, e-mail:   
> > > > > <mailto:jetspeed-dev-> unsubscribe@jakarta.apache.org> For
> > > > > additional commands, 
> > > > > e-mail: <mailto:jetspeed-dev-help@jakarta.apache.org>
> > > > > 
> > > > 
> > > > 
> > > > BBCi at http://www.bbc.co.uk/
> > > > 
> > > > This e-mail (and any attachments) is confidential and 
> may contain 
> > > > personal views which are not the views of the BBC unless
> > > specifically
> > > > stated.
> > > > If you have received it in error, please delete it from your
> > > > system, do 
> > > > not use, copy or disclose the information in any way nor act in 
> > > > reliance on it and notify the sender immediately. Please note 
> > > > that the 
> > > > BBC monitors e-mails sent or received. Further 
> communication will 
> > > > signify your consent to this.
> > > > 
> > > > 
> > > > --
> > > > To unsubscribe, e-mail:   
> > > > <mailto:jetspeed-dev-unsubscribe@jakarta.apache.org>
> > > > For additional commands, e-mail: 
> > > > <mailto:jetspeed-dev-help@jakarta.apache.org>
> > > > 
> > > 
> > > --
> > > To unsubscribe, e-mail:   
> > > <mailto:jetspeed-dev-> unsubscribe@jakarta.apache.org>
> > > For
> > > additional commands, 
> > > e-mail: <mailto:jetspeed-dev-help@jakarta.apache.org>
> > > 
> > 
> > 
> > BBCi at http://www.bbc.co.uk/
> > 
> > This e-mail (and any attachments) is confidential and may contain
> > personal views which are not the views of the BBC unless 
> specifically 
> > stated.
> > If you have received it in error, please delete it from your 
> > system, do 
> > not use, copy or disclose the information in any way nor act in 
> > reliance on it and notify the sender immediately. Please note 
> > that the 
> > BBC monitors e-mails sent or received. Further communication will 
> > signify your consent to this.
> > 
> > 
> > --
> > To unsubscribe, e-mail:   
> <mailto:jetspeed-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: 
> <mailto:jetspeed-dev-help@jakarta.apache.org>
> 
> --
> To 
> unsubscribe, e-mail:   
> <mailto:jetspeed-dev-> unsubscribe@jakarta.apache.org>
> For 
> additional commands, 
> e-mail: <mailto:jetspeed-dev-help@jakarta.apache.org>
> 


BBCi at http://www.bbc.co.uk/

This e-mail (and any attachments) is confidential and may contain 
personal views which are not the views of the BBC unless specifically 
stated.
If you have received it in error, please delete it from your system, do 
not use, copy or disclose the information in any way nor act in 
reliance on it and notify the sender immediately. Please note that the 
BBC monitors e-mails sent or received. Further communication will 
signify your consent to this.


--
To unsubscribe, e-mail:   <mailto:jetspeed-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:jetspeed-dev-help@jakarta.apache.org>


Mime
View raw message