Re: Transactions corruption and persistent connections
Thanks a lot Perrin, i will follow your recomendations... i've used the global variable for the database handler for simplicity and to avoid the local declaration and the method call, but i see the point in your advice. I will debug the code with more detail. Hans On Fri, 07 May 2004 18:16:48 -0400, Perrin Harkins wrote > On Fri, 2004-05-07 at 17:03, Hans Poo R. wrote: > > Fosis::handler is the main Dispatcher of the dynamic content. It can use the > > database handler via a Global variable $dbh > > It's not a good practice to put a database handle in a global. > Apache::DBI does it, but it also pings the handle before using it and > uses a cleanup handler to do a rollback. Putting it in your own global > could result in a dead handle getting used if you aren't careful. > > I'd suggest that you create an accessor function instead, like > Fosis::get_dbh(), and always call that to get a handle. (It's okay > to put it in a lexical variable temporarilly.) That function would call > DBI->connect() which will go through Apache::DBI. > > This might be the cause of the problems you're having, or it might > not, but it's definitely a red flag for me. > > > I turned on $Apache::DBI on level 2 of debugging and i've included the output > > of the error_log. It doesn't look so bad... > > It doesn't look bad to me either, but I still think you might want to > run through the debugger and look at where this problem occurs. Either > that, or add a bunch of logging to trace the execution path. I don't > know any other way to find out what's going on when that message is > generated. > > - Perrin Hans Poo, http://hans.opensource.cl, [EMAIL PROTECTED], F: 56-2-2010820 Santiago, Chile Consultor Linux. Desarrollo de Software OpenSource. -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: Transactions corruption and persistent connections
On Fri, 2004-05-07 at 17:03, Hans Poo R. wrote: > Fosis::handler is the main Dispatcher of the dynamic content. It can use the > database handler via a Global variable $dbh It's not a good practice to put a database handle in a global. Apache::DBI does it, but it also pings the handle before using it and uses a cleanup handler to do a rollback. Putting it in your own global could result in a dead handle getting used if you aren't careful. I'd suggest that you create an accessor function instead, like Fosis::get_dbh(), and always call that to get a handle. (It's okay to put it in a lexical variable temporarilly.) That function would call DBI->connect() which will go through Apache::DBI. This might be the cause of the problems you're having, or it might not, but it's definitely a red flag for me. > I turned on $Apache::DBI on level 2 of debugging and i've included the output > of the error_log. It doesn't look so bad... It doesn't look bad to me either, but I still think you might want to run through the debugger and look at where this problem occurs. Either that, or add a bunch of logging to trace the execution path. I don't know any other way to find out what's going on when that message is generated. - Perrin -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: Transactions corruption and persistent connections
Perrin
I have an InitHandler in a Files section (in order to promote perl i put this
extension to the files).
PerlInitHandler General::init_dbk
SetHandler perl-script
PerlHandler Fosis
Fosis::handler is the main Dispatcher of the dynamic content. It can use the
database handler via a Global variable $dbh, initialized en the init_db
process showed above, this database variable is defined in the General module
and is exported by default into the namespace in every module that uses the
module.
sub init_db {
$dbh = DBI->connect($dsn, $user, $pass, $options) or die "Imposible conectar
con la base de datos. " . DBI->errstr;
}
There is no more about the database connection in any side of the System.
I turned on $Apache::DBI on level 2 of debugging and i've included the output
of the error_log. It doesn't look so bad... at first glance it looks like some
connections are being reused. And the message: "Issuing rollback() for
database handle ..." isn't generated in all the requests.
# 1: report about new connect
# 2: full debug output
$Apache::DBI::DEBUG = 2;
Begin of output
--
17985 Apache::DBI push PerlCleanupHandler
17985 Apache::DBI need ping: yes
17985 Apache::DBI already connected to
'dbname=puente;host=localhost^\userid^\x^\AutoCommit=0^\PrintError=1^\RaiseError=1^\Username=userid'
17985 Apache::DBI PerlCleanupHandler
17985 Apache::DBI PerlCleanupHandler rollback for
dbname=puente;host=localhost^\userid^\x^\AutoCommit=0^\PrintError=1^\RaiseError=1^\Username=userid
18067 Apache::DBI PerlCleanupHandler
18067 Apache::DBI PerlCleanupHandler rollback for
dbname=puente;host=localhost^\userid^\x^\AutoCommit=0^\PrintError=1^\RaiseError=1^\Username=userid
17987 Apache::DBI push PerlCleanupHandler
17987 Apache::DBI need ping: yes
17987 Apache::DBI already connected to
'dbname=puente;host=localhost^\userid^\x^\AutoCommit=0^\PrintError=1^\RaiseError=1^\Username=userid'
17987 Apache::DBI need ping: no
17987 Apache::DBI already connected to
'dbname=puente;host=localhost^\userid^\x^\AutoCommit=0^\PrintError=1^\RaiseError=1^\Username=userid'
17987 Apache::DBI PerlCleanupHandler
17987 Apache::DBI PerlCleanupHandler rollback for
dbname=puente;host=localhost^\userid^\x^\AutoCommit=0^\PrintError=1^\RaiseError=1^\Username=userid
18071 Apache::DBI push PerlCleanupHandler
18071 Apache::DBI need ping: yes
18071 Apache::DBI new connect to
'dbname=puente;host=localhost^\userid^\x^\AutoCommit=0^\PrintError=1^\RaiseError=1^\Username=userid'
Issuing rollback() for database handle being DESTROY'd without explicit
disconnect().
18071 Apache::DBI PerlCleanupHandler
18071 Apache::DBI PerlCleanupHandler rollback for
dbname=puente;host=localhost^\userid^\x^\AutoCommit=0^\PrintError=1^\RaiseError=1^\Username=userid
18066 Apache::DBI push PerlCleanupHandler
18066 Apache::DBI need ping: yes
18066 Apache::DBI already connected to
'dbname=puente;host=localhost^\userid^\x^\AutoCommit=0^\PrintError=1^\RaiseError=1^\Username=userid'
18066 Apache::DBI PerlCleanupHandler
18066 Apache::DBI PerlCleanupHandler rollback for
dbname=puente;host=localhost^\userid^\x^\AutoCommit=0^\PrintError=1^\RaiseError=1^\Username=userid
18048 Apache::DBI push PerlCleanupHandler
18048 Apache::DBI need ping: yes
18048 Apache::DBI already connected to
'dbname=puente;host=localhost^\userid^\x^\AutoCommit=0^\PrintError=1^\RaiseError=1^\Username=userid'
18048 Apache::DBI PerlCleanupHandler
18048 Apache::DBI PerlCleanupHandler rollback for
dbname=puente;host=localhost^\userid^\x^\AutoCommit=0^\PrintError=1^\RaiseError=1^\Username=userid
17988 Apache::DBI PerlCleanupHandler
17988 Apache::DBI PerlCleanupHandler rollback for
dbname=puente;host=localhost^\userid^\x^\AutoCommit=0^\PrintError=1^\RaiseError=1^\Username=userid
17984 Apache::DBI push PerlCleanupHandler
17984 Apache::DBI need ping: yes
17984 Apache::DBI already connected to
'dbname=puente;host=localhost^\userid^\x^\AutoCommit=0^\PrintError=1^\RaiseError=1^\Username=userid'
17984 Apache::DBI PerlCleanupHandler
17984 Apache::DBI PerlCleanupHandler rollback for
dbname=puente;host=
Re: Transactions corruption and persistent connections
On Thu, 2004-05-06 at 12:42, Hans Poo R. wrote: > I removed the manual rollback and let the job to Apache::DBI, the problem is > that after the change, the message about the handle destroyed still appears in > the log. I activated the $Apache::DBI::DEBUG variable, but the message persist > (now with the DEBUG information). Does the debug info show that Apache::DBI is holding onto the connection or making a new connection every time? The error you're getting is one that DBI gives when a database handle goes out of scope (or gets explicitly undef'ed) without being disconnected. A handle that Apache::DBI is keeping persistent should not get DESTROY'd when it goes out of scope. You might want to run this in the debugger and see where this is happening. > It looks like it's a postgreSQL specific problem. I don't see anything PostgreSQL-specific in the errors you showed us. - Perrin -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: Transactions corruption and persistent connections
Hi Perrin I removed the manual rollback and let the job to Apache::DBI, the problem is that after the change, the message about the handle destroyed still appears in the log. I activated the $Apache::DBI::DEBUG variable, but the message persist (now with the DEBUG information). Issuing rollback() for database handle being DESTROY'd without explicit disconnect(). 24833 Apache::DBI new connect to 'dbname=;host=localhost xxx AutoCommit=0 PrintError=1 RaiseError=1 Username=' It looks like it's a postgreSQL specific problem. Hans On Wed, 05 May 2004 14:03:02 -0400, Perrin Harkins wrote > On Wed, 2004-05-05 at 13:01, Hans Poo R. wrote: > > I want to know, if it's necessary to rollback database connections on each > > request arrive with a PerlInitHandler, when using persistent database connections. > > Apache::DBI already does that for you in a cleanup handler. You are > using Apache::DBI, right? > > > The side effect of this manual rollback is that the error_log get filled with > > the message: > > > > Issuing rollback() for database handle being DESTROY'd without explicit > > disconnect() > > That's not normal. You shouldn't be getting anything in your error_log > from doing a rollback. You didn't show your code, so I can't speculate > on what's causing it. > > My advice is to remove your code and just let Apache::DBI do it. > > - Perrin -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: Transactions corruption and persistent connections
On Wed, 2004-05-05 at 13:01, Hans Poo R. wrote: > I want to know, if it's necessary to rollback database connections on each > request arrive with a PerlInitHandler, when using persistent database connections. Apache::DBI already does that for you in a cleanup handler. You are using Apache::DBI, right? > The side effect of this manual rollback is that the error_log get filled with > the message: > > Issuing rollback() for database handle being DESTROY'd without explicit > disconnect() That's not normal. You shouldn't be getting anything in your error_log from doing a rollback. You didn't show your code, so I can't speculate on what's causing it. My advice is to remove your code and just let Apache::DBI do it. - Perrin -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Transactions corruption and persistent connections
Hi all I'am using mod_perl-1.27, apache 1.3.28, Linux RedHat 9 and postgresql 7.4.2. I want to know, if it's necessary to rollback database connections on each request arrive with a PerlInitHandler, when using persistent database connections. This is the way i'am doing now (rolling back manually) in order to clean the transaction asociated to the connection, this is for the case where due to an abnormal situation a transaction get aborted but not rolled back, and some sql commands get in the middle. The side effect of this manual rollback is that the error_log get filled with the message: Issuing rollback() for database handle being DESTROY'd without explicit disconnect() I think that using this technique i'am losing the gain of persistence, but in ther other side avoid corruption of transactions. Finally, i allways use the next settings on DBI: RaiseError = 1 and AutoCommit = 0. That means i commit manually when transactions are succesfull. Thanks. Hans Poo, Chile -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
