portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Sean Taylor" <da...@bluesunrise.com>
Subject RE: DatabasePsmlManagerService
Date Sun, 30 Jun 2002 02:35:03 GMT


> -----Original Message-----
> From: Glenn Golden [mailto:ggolden@umich.edu] 
> Sent: Saturday, June 29, 2002 6:45 PM
> To: Jetspeed-Dev (jetspeed-dev@jakarta.apache.org)
> Subject: DatabasePsmlManagerService
> 
> 
> I've got some changes to the DatabasePsmlManagerService to 
> drastically reduce the number of hits against the db, or, in 
> other words, greatly improve it's caching.
> 
> Currently, it is using a "WeakHashmap" to cache psml docs.  
> In my experience with it, docs are rarely found in the cache. 
>  They sometimes are, and I think this is when there's an 
> overlapping request for a doc or successive
> doc requests without a garbage collect in between.   But 
> usually, the cache
> is empty.  This is consistent with my read of what a WeakHashmap does.
> 
> In addition, the profiler tries a series of locator 
> combinations until a page is found.  In my setup, it always 
> tries three, and the third one finds my psml doc.  These 
> first two requests happen each time, even if the successful 
> one has been cached.
> 
> Here's my changes:
> 
> First, I use a Hashmap instead of a weak one.  Let it cache.  
> The class has a thread which refreshes the cache from the db 
> to handle changes made to the db behind Jetspeed's back.

+1 on replacing the WeakHashMap. I've experienced the same problem also
in the Castor impl.

The thread sounds ok, as long as you can configure how often it runs.
Did you use the Turbine's scheduler? Its dead easy to use and reliable.
The TurbineNonPersistentSchedulerService configures everything in the
TR.p, not in db.
I think in the long run I'd prefer something like JCS
http://jakarta.apache.org/turbine/jcs, but for now this will do fine.

> Second, I am caching failures as well as successes.  Those 

+1 Great, that's on my todo list.
Im also planning on caching misses in the Castor (default) impl

> first two locators will be found, and found as null, in the 
> cache, so the db does not have to be consulted each request, 
> once we know they are NOT there.  These will also be 
> refreshed by the refreshing thread - left null or filled in.
> 
> The result is a significant reduction of db hits for pages 
> when the application has frequent requests for a page or many 
> users using the same page (my app does both!).
> 
> I'm happy to check this in, sharing the improvements.  Any 
> comments?  Any concerns?
> 
Just that I hope you can get it in very soon if at all possible.
I'd like to propose that we do a release by the end of next week...


David

> 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>
> 
> 



--
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