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 17:17:31 GMT
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>


Mime
View raw message