On Mon, Oct 18, 1999 at 07:08:09AM -0700, Michael Peppler wrote:
> Tim Bunce writes:
> > On Fri, Oct 15, 1999 at 11:42:29AM +0100, Matt Sergeant wrote:
> > > On Fri, 15 Oct 1999, Perrin Harkins wrote:
> > > > On Thu, 14 Oct 1999, Jeffrey Baker wrote:
> > > > > Zero optimization: 41.67 requests/second
> > > > > Stage 1 (persistent connections): 140.17 requests/second
> > > > > Stage 2 (bound parameters): 139.20 requests/second
> > > > > Stage 3 (persistent statement handles): 251.13 requests/second
> > > >
> > > > I know you said you don't like it because it has extra overhead, but would
> > > > you mind trying stage 3 with prepare_cached rather than your custom
> > > > solution with globals? For some applications with lots of SQL statements,
> > > > the prepare_cached appraoch is just much more manageable.
> > >
> > > Sadly prepare_cached doesn't always work very well - at least not with
> > > Sybase (and I assume MSSQL). Just a warning.
> >
> > Could you be more specific?
>
> I've never looked at prepare_cached() for DBD::Sybase, and Matt tried
> it out and it appeared not to work.
"appeared not to work" isn't much more specific :-)
> I would guess that this is again
> an issue of having to open multiple connections if you prepare more
> than one statement.
Here's the code:
sub prepare_cached {
my ($dbh, $statement, $attr, $allow_active) = @_;
my $cache = $dbh->FETCH('CachedKids');
$dbh->STORE('CachedKids', $cache = {}) unless $cache;
my $key = ($attr) ? join(" | ", $statement, %$attr) : $statement;
my $sth = $cache->{$key};
if ($sth) {
Carp::croak("prepare_cached($statement) statement handle $sth is still
active")
if !$allow_active && $sth->FETCH('Active');
return $sth;
}
$sth = $dbh->prepare($statement, $attr);
$cache->{$key} = $sth if $sth;
return $sth;
}
Tim.
