Mailing-List: contact modperl-help@perl.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: pass (asf.osuosl.org: domain of mpeters@plusthree.com designates
 207.114.11.197 as permitted sender)
Message-ID: <43F0713E.5070704@plusthree.com>
Date: Mon, 13 Feb 2006 06:45:02 -0500
From: Michael Peters <mpeters@plusthree.com>
User-Agent: Mozilla Thunderbird 1.0.7-1.1.fc3 (X11/20050929)
MIME-Version: 1.0
To: RJ Herrick <rjherrick@sbcglobal.net>
CC: mod_perl List <modperl@perl.apache.org>
Subject: Re: Need to clean MySQL handle attributes with persistant handle?
References: <43F01C8E.8020200@sbcglobal.net>
In-Reply-To: <43F01C8E.8020200@sbcglobal.net>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


RJ Herrick wrote:
> Hi all,
> Under mod_perl, what is the correct, safe protocol for using the handle
> attribute mysql_insertid from a persistant handle? Am I correct in
> thinking that I need to clean up attributes like {mysql_insertid}if I
> want to ensure that they are specific to my current call?
> Specifically, could I try to retrieve $dbhandle->{mysql_insertid} after
> a failed insert and accidentally end up with an insertid from a previous
> call? If so, would the best way to guard against this for each use be:
> 
>   $dbhandle->{mysql_insertid} = undef;
>   #Attempt insert here
>   $inserted_id = $dbhandle->{mysql_insertid};
> 
> I went looking and couldn't find anything specifically referencing use
> of the mysql_insertid function call in DBD::mysql.with mod_perl in mind.
> I can't even find the insertid functionality in DBD::mysql, but maybe
> I'm just too tired... Any tangentially related advice would probably
> also be appreciated. Thanks!

First off I think it will help to tell you that MySQL (or database connections
in general) are not shared between Apache children. Even if you're using
Apache::DBI, you will have "persistant" (not disconnected) connections , not
"pooled" (shared) connections.

Having said that, if you're concerned that a child previously attempted an
insert, failed and then started serving your current request then that might be
something different. The database handles by default don't know anything about
different request under mod_perl so you have to do something to let them know.
Apache::DBI solves this by doing the following:

  In order to avoid inconsistencies in the database in case AutoCommit is off
  and the script finishes without an explicit rollback, the Apache::DBI module
  uses a PerlCleanupHandler to issue a rollback at the end of every request.

So if you're using Apache::DBI then everything should be ok. Else, you'll need
you're own similar PerlCleanupHandler.

HTH
-- 
Michael Peters
Developer
Plus Three, LP