On Mon, 2006-01-16 at 23:15 +0000, Jeremy Nixon wrote:
> That code has to work identically in or out of mod_perl, so it can't
> have any mod_perl-specific stuff inside it.
I usually handle that by checking $ENV{MOD_PERL}:
our %CACHE;
sub set_value {
my ($key, $value) = @_;
if ($ENV{MOD_PERL}) {
Apache->request->pnotes($key, $value);
} else {
$CACHE{$key} = $value;
}
}
> Read committed is no problem, since it's the default
Unfortunately, InnoDB defaults to "repeatable read", so I always have to
change it.
> DBI won't let you do the latter at all, it just tells you to use DBI
> methods for transactions, and there is no DBI method for that.
Maybe you should ask on the dbi-users list to see what other people do.
There must be others who have dealt with this.
> You can't
> do the first option when AutoCommit is off, because you can't do "begin",
> but if you do the "set transaction" it tells you there is no transaction
> open.
InnoDB always has a transaction open, even in AutoCommit. Very
different behavior.
> So I have to turn AutoCommit on, open a transaction, then send
> the "set transaction" query. Then I have to remember, for that particular
> database handle, to put AutoCommit back where it was before after a
> commit or rollback -- which means I have to keep state on each handle I
> have open.
You can sometimes use local() to good effect:
{
local $dbh->{AutoCommit} = 1;
... do some stuff ...
}
At the end of the block, it goes back to whatever state it was in
before.
> My bet, though, is that I messed up somewhere in the logic
> that caches my instances, trying to be a little too clever.
That would explain the behavior you described.
> Anyway, I now have all this code that doesn't use prepared statements
> at all, so I'm not in a good position to quickly try it
There are definite speed benefits to using prepare_cached, especially
with a database like Pg that has server-side prepared statements. You
may want to experiment with it again in the future.
- Perrin
