On Wednesday, October 17, 2001, at 03:23 PM, Tim Harsch wrote:
> 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... That's a good point based on my example ... why cache SQL when you can cache the page the SQL is generating. But webservers was an example. In general, we might be dealing with a farm of Net::FTPServer processes or Net::Server processes or something else which will be making parallel equivalent queries from different processes. > >> -----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. >> >
