Apache::DBI claims that it will reconnect to a database if it's gone away.
DBD::Pg claims that it supports the ping method. However, when I restart my
database server while apache2 is running, all mod_perl pages that are
database driven return internal server errors, no matter how many times I
refr
Tyler MacDonald wrote:
[Fri Jan 13 23:46:28 2006] [error] [client 192.168.99.112] DBD::Pg::db
prepare_cached failed
Do you only have the problem with prepare_cached? Can you replicate it
in a small script that just connects and does the prepare_cached if you
restart the database?
- Perrin
Tyler MacDonald <[EMAIL PROTECTED]> wrote:
> [Fri Jan 13 23:46:28 2006] [error] [client 192.168.99.112] DBD::Pg::db
> prepare_cached failed: FATAL: terminating connection due to administrator
Here's the thing: if your database connection goes away, and Apache::DBI
opens a new one, any prepared s
On Sun, Jan 15, 2006 at 02:00:15AM +, Jeremy Nixon wrote:
> Tyler MacDonald <[EMAIL PROTECTED]> wrote:
>
> > [Fri Jan 13 23:46:28 2006] [error] [client 192.168.99.112] DBD::Pg::db
> > prepare_cached failed: FATAL: terminating connection due to administrator
>
> Here's the thing: if your data
Jeremy Nixon wrote:
Here's the thing: if your database connection goes away, and Apache::DBI
opens a new one, any prepared statement handles you might have become
invalid, because prepared statements are per-connection.
The prepare_cached() method he's using will check the statement handle
and
Perrin Harkins <[EMAIL PROTECTED]> wrote:
> The prepare_cached() method he's using will check the statement handle
> and prepare it again on the new connection if necessary.
Not with Apache::DBI, though. The reconnect happens underneath DBI, and
you end up with the same $dbh, which thinks the
On Sun, 2006-01-15 at 23:11 +, Jeremy Nixon wrote:
> Perrin Harkins <[EMAIL PROTECTED]> wrote:
>
> > The prepare_cached() method he's using will check the statement handle
> > and prepare it again on the new connection if necessary.
>
> Not with Apache::DBI, though. The reconnect happens u
Perrin Harkins <[EMAIL PROTECTED]> wrote:
> my $cache = $dbh->FETCH('CachedKids');
>
> That should return cached handles from the current $dbh, not an old one
> that has been replaced. The statement handles are attached to the
> database handle, so if it gets replaced, all the old ones go away.
On Sun, 2006-01-15 at 23:35 +, Jeremy Nixon wrote:
> Perrin Harkins <[EMAIL PROTECTED]> wrote:
>
> > my $cache = $dbh->FETCH('CachedKids');
> >
> > That should return cached handles from the current $dbh, not an old one
> > that has been replaced. The statement handles are attached to the
>
Perrin Harkins <[EMAIL PROTECTED]> wrote:
> If you have some code that is caching $dbh in a global or closure, and
> not calling Apache::DBI->connect() on every request, it can't replace
> that, and neither can DBI->connect_cached(). That defeats the auto-
> reconnect features of both. I recom
On Mon, 2006-01-16 at 05:11 +, Jeremy Nixon wrote:
> I'm not caching across requests; I have a cleanup handler that
> calls rollback and disconnect, and then nukes my entire db wrapper from
> orbit.
You keep the handle in a global and then clear it from a cleanup
handler? That should work, bu
Perrin Harkins <[EMAIL PROTECTED]> wrote:
> Tyler MacDonald wrote:
> >[Fri Jan 13 23:46:28 2006] [error] [client 192.168.99.112] DBD::Pg::db
> >prepare_cached failed
>
> Do you only have the problem with prepare_cached? Can you replicate it
> in a small script that just connects and does the pre
Jeremy Nixon <[EMAIL PROTECTED]> wrote:
> It looks like it would work perfectly with connect_cached, which I hadn't
> known about, but now that I do, I'm all excited to change my code to use
> it instead of Apache::DBI.
*instead*, eh... I'm using it as well... Could this be part of the
pro
> On the other hand, I have some funky code going on after trying to deal
> with DBI's handling of transactions -- I don't want AutoCommit, but it
> seems to be impossible to do "set transaction isolation level serializable"
> without it, because DBI won't open a transaction if you send that comman
On Mon, 2006-01-16 at 12:39 -0800, Tyler MacDonald wrote:
> Thanks after looking over the messages in the (rather large)
> thread this has spawned over the weekend, I played around a little bit, and
> found I had a package that was cacheing it's database handle in a global. I
> ended up w
Perrin Harkins <[EMAIL PROTECTED]> wrote:
> You keep the handle in a global and then clear it from a cleanup
> handler?
I actually keep it in an object instance, but same thing, since I'm
caching the object in a global that gets removed from a cleanup handler.
The object wraps all the functional
On Mon, Jan 16, 2006 at 12:42:10PM -0800, Tyler MacDonald wrote:
> Jeremy Nixon <[EMAIL PROTECTED]> wrote:
> > It looks like it would work perfectly with connect_cached, which I hadn't
> > known about, but now that I do, I'm all excited to change my code to use
> > it instead of Apache::DBI.
>
>
On Mon, 2006-01-16 at 23:15 +, 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_PE
On Mon, 16 Jan 2006 23:15:59 + (UTC), Jeremy Nixon wrote:
> There are two
> ways to put a transaction into that mode: you can open a transaction and
> then "set transaction isolation level serializable", or you can open the
> transaction by doing "begin transaction isolation level serializable"
On Tue, 2006-01-17 at 16:06 +, Peter Haworth wrote:
> I haven't tested any of these, since I haven't needed to change the isolation
> level since the bad old days of Illustra, when "read uncommitted" was
> necessary to even approach reasonable performance on our horrible system.
Wow, I thought
20 matches
Mail list logo
