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:[EMAIL PROTECTED]] > 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:[EMAIL PROTECTED]] > > Sent: 23 September 2002 18:04 > > To: 'Jetspeed-Dev ([EMAIL PROTECTED])' > > 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 > > [EMAIL PROTECTED] 734-615-1419 > > -------------------------------------------- > > > > > > -- > > To unsubscribe, e-mail: > > <mailto:jetspeed-dev-> [EMAIL PROTECTED]> > > For > > additional commands, > > e-mail: <mailto:[EMAIL PROTECTED]> > > > > > 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:[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]>
