Mailing-List: contact modperl-help@perl.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: pass (herse.apache.org: local policy)
In-Reply-To: <edcafa7d0705310832w34d548e5wb179f284ddc53ba@mail.gmail.com>
References: <edcafa7d0705310832w34d548e5wb179f284ddc53ba@mail.gmail.com>
Mime-Version: 1.0 (Apple Message framework v752.2)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <C2265E1F-B962-4AF2-991E-FAACFEA32E3B@2xlp.com>
Cc: "mod_perl mod_perl" <modperl@perl.apache.org>
Content-Transfer-Encoding: 7bit
From: Jonathan Vanasco <jvanasco@2xlp.com>
Subject: Re: mod_perl forking and DBD::Pg prepared statement problem
Date: Thu, 31 May 2007 12:27:02 -0400
To: Aaron Trevena <aaron.trevena@gmail.com>


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
| - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -  
- - - - - - - - - - - - - - - - - - -