DBI, bind_cols and concurrency

jcabraham has asked for the wisdom of the Perl Monks concerning the following question:

I have an app using Class::DBI, hitting a Postgres database, running under mod_perl(1.0). Everything works fine unless there are relatively simultaneous attempts to fetch a given page, which fetches a Class::DBI object and displays it. When this happens, I get a DBI bind_col error: bind_col: column 2 is not a valid column (1..1) at /usr/local/lib/perl5/site_perl/5.8.0/i686-linux/DBI.pm line 1797The column in question varies, depending upon which class/db table is being accessed. It may be a DBIx::ContextualFetch problem, but the error is right out of the DBI xs stub. Again, this only occurs when there are simultaneous requests. Further debugging makes me think that different handler processes under mod_perl are getting the wrong database statement handles. Anyone have this problem with DBI and mod_perl? Jim

Comment on DBI, bind_cols and concurrency

Replies are listed 'Best First'.
Re: DBI, bind_cols and concurrency by perrin (Chancellor) on Oct 19, 2005 at 15:22 UTC
This sounds like some kind of library mismatch problem. I'd suggest recompiling your DBI and DBD::Pg modules, and making sure that the perl on your system is the one that mod_perl was built with.	[reply]
Re^2: DBI, bind_cols and concurrency by jcabraham (Novice) on Oct 21, 2005 at 01:50 UTC
You posted a patch to Ima::DBI to fix problems with cached db handles under mod_perl. I'm now sorta convinced that the problem I'm having is with cached statement handles. You never experienced this? Why change the db handle caching and not that of the statement handles? Jim	[reply]
Re^3: DBI, bind_cols and concurrency by perrin (Chancellor) on Oct 21, 2005 at 02:32 UTC
The code in Ima::DBI actually calls the database handle cache whenever fetching a statement handle, so it only needs to be patched in one place. I now think the most likely explanation here is what Errto suggested: you are opening a database handle in the parent process, maybe with a setup_table() call. My patch will fix this for you.	[reply]
Re: DBI, bind_cols and concurrency by Errto (Vicar) on Oct 19, 2005 at 16:25 UTC
The only thing I can think of is if you are trying to share a database connections between multiple Apache processes. This could happen if you open a connection in a startup script and store it in a global variable and then access it from individual scripts. That generally won't work.	[reply]
Re: DBI, bind_cols and concurrency by LanceDeeply (Chaplain) on Oct 19, 2005 at 13:48 UTC
i dont have a good answer for you, just an ugly hack to help you get by until you find the answer: you can create a mutex with flock right before the code you believe is suspect ( ... which fetches a Class::DBI object and displays it ... ) and release the filelock after you're done with the suspect area. -hth	[reply]