Re^2: Class::DBI and mod

Thanks for your work on this, perrin. One question - the only place I can find "private_cache_key_pid" is in this code snippet, where it is only assigned. Is this a custom attribute for DBI that is in a locally modified copy?

I'm trying to use this in conjunction with Class::DBI, and when I paste this into my DBI class, instead of "fetch before execute" errors in the parent, I'm getting "server has gone away". I'm setting InactiveDestroy on all the children, but the best I can figure is that somewhere Class::DBI is breaking my connection in its own DESTROY handlers. I don't actually use DBI in the children, it's just that the fork behavior breaks the parent's connection.

As you know, Ima::DBI creates closures and I likely have a ton of references to it in child "memory", so it's not as simple as setting InactiveDestroy and undefining a handle. =\

mhoward - at - hattmoward.org

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

Replies are listed 'Best First'.
Re^3: Class::DBI and mod_perl 2 by perrin (Chancellor) on Jun 12, 2007 at 19:14 UTC
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.	[reply]
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]