Sorry, please disregard the below mail. The problem was in the
application server area that was caching and pointing to the old $dbh.
That made me realize that I need to implement a callback cleanup
function to allow for spring cleaning of any stray $dbh on the app level.
Unless there's another way that I can't think about.
H
Henri Asseily wrote:
> 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
--
Henri Asseily BizRate.com
[EMAIL PROTECTED] The best shopping experience!
Chief Technologist http://www.bizrate.com/
"Apprends mon ami que la situation la mieux assise ne
r�siste pas au pal." Iznogoud
