I am wondering if Terence has considered using a caching web server... Oracle says 9i is so goof at it... not sure I believe that... but still it sounds like maybe it might help Terence so he doesn't have to roll his own result caching alroithms if all he is trying to do is performance enhance many CGIs that hit the database... and if not sorry for the distraction...
> -----Original Message----- > From: Tim Bunce [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, October 17, 2001 2:48 AM > To: Terrence Brannon > Cc: [EMAIL PROTECTED] > Subject: Re: RFCs: DBI.pm source code and Module proposal > > > [moved to dbi-dev list] > > On Tue, Oct 16, 2001 at 07:22:11PM -0700, Terrence Brannon wrote: > > As it stands, neither the algorithm or results of DBI's prepare_cached > > and connect_cached key routines are directly useable in > subclasses... in > > other words the actual key generated is not stored in an attribute of > > the handle AND the actual algorithm used to generate these keys is > > inlined and not separately callable. > > > > The import of the above observations is that subclasses or container > > classes making use of DBI cannot access or easily re-use this cache key > > text for it's own purposes. > > > > The module I propose to develop (the second RFC of this email), > makes it > > clear why this would be useful. > > Er, actually it's not very clear to me. > > > ** Module Proposal: Net::DBI or DBI::Cache ** > > > > motivation - DBI currently caches statement handles and > database handles > > within a single process. It does no caching of query results either > > within or between processes. Thus if 50 front-end webservers > are all hit > > with the same query, the best you can do is get a cache of the > statement > > handle and re-execute. An optimal solution would not only cache the > > statement handle but also the query results, alleviating all > > un-necessary and repetitive database load. > > What's that got to do with subclassing > prepare_cached/connect_cached, exactly? > > Are you trying to add global result-caching by just connecting > via a subclass? > > I've long planned to add result-caching but I don't think it's that > simple (in general) and doing it globally (without per-query coding) > is probably not what most people want. > > (I'd expect it to grow out of adding a 'cursor library' and > fetch_scroll() [or whatever it's called] method and saving/reusing > the data cache that that would need. But that doesn't preclude other > approaches.) > > Tim. >
