I'm working on a high-availability database switching module to work
with DBI and Apache::DBI, and I'll release it as soon as it's ready.
But I have one last problem:
it seems that even if I do the following:
eval { $dbh->DESTROY unless $dbh; undef $dbh; }
the dbh isn't really wiped.
Here's what I do:
Using a sql tool, I kill my live database connections from within the
database.
Then I load a page. The execute dies. I reconnect and reexecute it.
To do this, first I remove the entry in the Apache::DBI hash of cached
dbh's if we're running Apache::DBI.
Second, I do the eval statement above (DESTROY, etc..).
Third, I retry $dbh = DBI->connect. In this situation, it works.
Then I prepare the statement (no problem there, ever)
Finally, I reexecute the sql using this theoretically new dbh.
At that point, it will tell me all is well and the statement executed
properly, but it really didn't.
It returns an empty set as seen by and fetch statement.
It's only when I try to reload the page or go to another page that the
dbh is really wiped, and a clean one put in its place.
So my question is:
How do I really wipe a dbh from memory, totally, completely and with
prejudice?
Obviously Apache::DBI seems to do it at request cleanup, but I can't see
how.
PS: That code will allow you to seamlessly set up your infrastructure
with many replicated DB servers, and have your perl/mod_perl scripts be
totally oblivious to it. It will have overflow capabilities on a
per-child basis, as well as full-server failover when dbs are read/write
and you keep a live/hot-standby system.
I believe nobody's done that before. Or am I hopefully wrong?
---
Henri Asseily
[EMAIL PROTECTED]
Chief Technology Officer
BizRate.com
"Que les inop�rants laissent passer ceux qui font"
Achille Talon
