The thread code was already there - I'm not going to mess with it. Other than that, I could check it in anytime. I'm putting it into production (test) tonight, and I'll see if there are any problems.
- Glenn -------------------------------------------- Glenn R. Golden, Systems Research Programmer University of Michigan School of Information [EMAIL PROTECTED] 734-615-1419 -------------------------------------------- > -----Original Message----- > From: David Sean Taylor [mailto:[EMAIL PROTECTED]] > Sent: Saturday, June 29, 2002 10:35 PM > To: 'Jetspeed Developers List' > Subject: RE: DatabasePsmlManagerService > > > > > > -----Original Message----- > > From: Glenn Golden [mailto:[EMAIL PROTECTED]] > > Sent: Saturday, June 29, 2002 6:45 PM > > To: Jetspeed-Dev ([EMAIL PROTECTED]) > > 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 > > [EMAIL PROTECTED] 734-615-1419 > > -------------------------------------------- > > > > -- > > To unsubscribe, e-mail: > > <mailto:jetspeed-dev-> [EMAIL PROTECTED]> > > For > > additional commands, > > e-mail: <mailto:[EMAIL PROTECTED]> > > > > > > > > -- > To unsubscribe, e-mail: > <mailto:jetspeed-dev-> [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]>
