aaron-
I think this may be more of a Maypole design issue than a mod_perl
issue -- although there may also be a bit of an application design
issue on your part ( which some of your wording suggests ) , and
there may be a dbd::pg issue as well.
my input:
1:
potential issue in your application:
you should be using a startup.pl file to preload the maypole files
and your appplication files. that will compile everything on startup.
i'm assuming you're not doing that already , because of some wording
in your text -- you should be trying to compile everything into
apache yourself, not worrying about virtualhosts or apachemain sections.
2:
potential issue with maypole / apache
your setup might be preparing the statements before the fork .
maybe you're using apache::dbi and doing an outright connect, not a
connect on init ? or using a global db connection?
make sure that you don't connect at all, or do a forceful
disconnect on your db handles before you fork, so each apache child
has a fresh db connection for itself.
newer versions of apache::dbi should do this already, but it doesn't
hurt to force it to disconnect ( disconnect is overloaded, so $dbh-
>disconnect doesn't work, you need to DBI::Whatever::disconnect
( $dbh ) )
3:
potential issue with dbd::pg / dbi
in 1.48(?) there was some issue with the way that prepared statments
were cached. i think the fix was to simply include the PID of the
process that created them. i'm a bit confused on the whole topic,
because there was a lot of blame going back and forth about a year
ago -- dbi said it was the dbd problem, dbd said it was an
apache::dbi problem, apache::dbi said it was a user config problem.
eventually most things got patched to circumvent the situation from
happening.
make sure you're up to date
i hope that helps.
On May 31, 2007, at 11:32 AM, Aaron Trevena wrote:
Hello you wonderful helpful people :)
I've just moved a web application (maypole/c::dbi) from one
development server to another, previously the code worked fine but now
I get :
'prepared statement "dbdpg_1" does not exist' on every (prepared)
query to the database.
There only are two differences: the version of postgres and the apache
configuration - other than that the dependancies all match.
On the problem server the perl content handler is in a location
outside of a virtual host, in the working server is in a location
inside a virtual host.
The problem server also has postgres 8.1 and the working server has
postgres 7.4 - this shouldn't make any difference (although 8.1 is
backwards incompatible enough to have caused problems previously with
querys no longer being valid *sigh*).
So my question is - will having a content handler in a location
directive outside of virtual host cause it to be compiled before
forking, and after forking if inside a virtual host? As pre-forking
seems to be blamed in the few examples I could find with google.
// Jonathan Vanasco
| - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - - - - - -
| SyndiClick.com
| - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - - - - - -
| FindMeOn.com - The cure for Multiple Web Personality Disorder
| Web Identity Management and 3D Social Networking
| - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - - - - - -
| RoadSound.com - Tools For Bands, Stuff For Fans
| Collaborative Online Management And Syndication Tools
| - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - - - - - -
