Re^3: Class::DBI and mod

Read the section in the DBI docs about connect_cached. It comes from there.

By the way, I recently released a new version of Ima::DBI which includes this patch, but doesn't use threads->tid. If you can verify that threads->tid works for you, I could put it in the main Ima::DBI distribution so you wouldn't need to patch it.

Comment on Re^3: Class::DBI and mod_perl 2

Replies are listed 'Best First'.
Re^4: Class::DBI and mod_perl 2 by meredith (Friar) on Jun 12, 2007 at 19:22 UTC
Ah, I see. It's just extra safety beyond the check for "$process_id == $$" right? Thanks for mentioning the update. I just bumped up from 0.34 and removed the snippet from my module. Unfortunately this does just cause the same behavior, but at least I got an update. ;) I think I'll have to use my own db_Main so I have control of the original dbh object somewhere. I'm not using threads, so I'll assume that is directed at the OP. :) `mhoward - at - hattmoward.org`	[reply]
Re^5: Class::DBI and mod_perl 2 by perrin (Chancellor) on Jun 12, 2007 at 19:37 UTC
Sorry, I thought you were the OP. Setting the private attribute prevents connect_cached from replacing the existing dbh in its cache with a new one. It is intended to help with forking, where you don't want to trigger a DESTROY call on the old handle because it may tell the server it's disconnecting and thus screw up the connection in the parent process where you want it to work. Working with a forking server is really tricky if you want the handle in the parent to keep working. I suspect you missed a connection when you set InactiveDestroy. If, for example, you use a module like Proc::Daemon, it does a fork of its own, and you muse set InactiveDestroy on the handles it opens before forking, or they will break things later.	[reply]