portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Luta, Raphael (VUN)" <Raphael.L...@groupvu.Com>
Subject RE: Bug in JetspeedAccessController re: Profile
Date Mon, 23 Sep 2002 17:30:13 GMT
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>


Mime
View raw message