Apache::DBI
Hello, every body
I can run the following subroutine in DBI, but Apache::DBI...
use DBI;
sub connect{
$dbh = DBI-connect(dbi:Pg:dbname=test, canis,3dsadasz);
$sth = $dbh-prepare(SELECT clave, denominacion FROM Marca)
|| die $dbh-errstr;
$sth-execute() || die $sth-errstr;
while(my $row = $sth-fetch){
my($clave, $nombre) = @$row;
print clave = $clave, denominacion = $nombre\n;
}
$dbh-disconnect;
}
and I have this log...
[Thu Aug 28 12:36:44 2003] [error] (2)No such file or directory: mod_mime_magic:
can't read magic file /etc/apache-perl/share/magic
[Thu Aug 28 12:36:45 2003] [notice] Apache/1.3.26 (Unix) Debian GNU/Linux
mod_perl/1.26 configured -- resuming normal operations
[Thu Aug 28 12:36:45 2003] [notice] suEXEC mechanism enabled (wrapper:
/usr/lib/apache/suexec)
[Thu Aug 28 12:36:45 2003] [notice] Accept mutex: sysvsem (Default: sysvsem)
[Thu Aug 28 12:37:03 2003] null: DBI-connect(dbname=test) failed: FATAL 1:
IDENT authentication failed for user canis at /var/lib/perl/JCVA/Conexion.pm
line 11
[Thu Aug 28 12:37:03 2003] [error] Can't call method prepare on an undefined
value at /var/lib/perl/JCVA/Conexion.pm line 13.
Somedody knows if the user must be registered in some configuration file?
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
Re: Apache::DBI
It looks like your PostgreSQL installation is trying to do IDENT
authentication, instead of MD5. So, it's checking the user your script is
running as, and trusting that since you managed to log on with your
username/password already, it'll trust you to log into the database.
While this isn't strictly an Apache problem, but rather a database problem,
here's what's probably the matter. In your /var/lib/pgsql/data/pg_hba.conf
file, you probably have the default:
local all all trust
I would suggest changing this to something like:
local all all md5
or make it IP based:
host allall1.2.3.4255.255.255.255 md5
you get the idea. That way, it'll obey the username/password that you supply.
On Thursday 28 August 2003 04:28 pm, wrote:
Hello, every body
I can run the following subroutine in DBI, but Apache::DBI...
use DBI;
sub connect{
$dbh = DBI-connect(dbi:Pg:dbname=test, canis,3dsadasz);
$sth = $dbh-prepare(SELECT clave, denominacion FROM Marca)
|| die $dbh-errstr;
$sth-execute() || die $sth-errstr;
while(my $row = $sth-fetch){
my($clave, $nombre) = @$row;
print clave = $clave, denominacion = $nombre\n;
}
$dbh-disconnect;
}
and I have this log...
[Thu Aug 28 12:36:44 2003] [error] (2)No such file or directory:
mod_mime_magic: can't read magic file /etc/apache-perl/share/magic
[Thu Aug 28 12:36:45 2003] [notice] Apache/1.3.26 (Unix) Debian GNU/Linux
mod_perl/1.26 configured -- resuming normal operations
[Thu Aug 28 12:36:45 2003] [notice] suEXEC mechanism enabled (wrapper:
/usr/lib/apache/suexec)
[Thu Aug 28 12:36:45 2003] [notice] Accept mutex: sysvsem (Default:
sysvsem) [Thu Aug 28 12:37:03 2003] null: DBI-connect(dbname=test) failed:
FATAL 1: IDENT authentication failed for user canis at
/var/lib/perl/JCVA/Conexion.pm line 11
[Thu Aug 28 12:37:03 2003] [error] Can't call method prepare on an
undefined value at /var/lib/perl/JCVA/Conexion.pm line 13.
Somedody knows if the user must be registered in some configuration file?
--
/* Michael A. Nachbaur [EMAIL PROTECTED]
* http://nachbaur.com/pgpkey.asc
*/
Another world, another day, another dawn.
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
Apache::DBI
I can run the following code with DBI
but in Apache::DBI.
#!/usr/bin/perl -w
use DBI;
sub connect{
$dbh = DBI-connect(dbi:Pg:dbname=test, canis,$password);
$sth = $dbh-prepare(SELECT clave, denominacion FROM Marca)
|| die $dbh-errstr;
$sth-execute() || die $sth-errstr;
while(my $row = $sth-fetch){
my($clave, $nombre) = @$row;
print clave = $clave, denominacion = $nombre\n;
}
$dbh-disconnect;
I have this log...
[Thu Aug 28 12:36:44 2003] [error] (2)No such file or directory: mod_mime_magic:
can't read magic file /etc/apache-perl/share/magic
[Thu Aug 28 12:36:45 2003] [notice] Apache/1.3.26 (Unix) Debian GNU/Linux
mod_perl/1.26 configured -- resuming normal operations
[Thu Aug 28 12:36:45 2003] [notice] suEXEC mechanism enabled (wrapper:
/usr/lib/apache/suexec)
[Thu Aug 28 12:36:45 2003] [notice] Accept mutex: sysvsem (Default: sysvsem)
[Thu Aug 28 12:37:03 2003] null: DBI-connect(dbname=test) failed: FATAL 1:
IDENT authentication failed for user canis at /var/lib/perl/JCVA/Conexion.pm
line 11
[Thu Aug 28 12:37:03 2003] [error] Can't call method prepare on an undefined
value at /var/lib/perl/JCVA/Conexion.pm line 13.
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
Re: Apache::DBI not really loading
I've set Apache::DBI::DEBUG to 2, and I'm not seeing _any_ messages (from it) in the error log. Apache::Status lists Apache DBI, but lists no database connections. A long time ago, one problem used to be that if your connect to Postgres was idle for too long ( 8 hours ) the connection would timeout and give you these kinds of errors. One solution was to make sure that you hit a web page that has such a connection periodically, 1) Wasn't this problem corrected by using the ping() method? 2) I'm hoping for a clue why Apache::DBI is there but not giving any messages or having any connections in Apache::Status 3) Avoiding timeout doesn't help when the network hiccups and drops existing connections (I don't admin the network, can't change that) This may not be related to your current problem, so YMMV. Doesn't appear helpful, but I appreciate some response :) -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Apache::DBI not really loading
I've got a case where my DBI connections appear to be timing out and not reconnecting. Google just points to the old timeout problem that should be solved. I've set Apache::DBI::DEBUG to 2, and I'm not seeing _any_ messages (from it) in the error log. Apache::Status lists Apache DBI, but lists no database connections. Advice most welcome Perl version v5.6.1 for Apache/1.3.27 (Unix) AuthPG/1.2 mod_perl/1.27 Database is Postgres (I can dig up version, but it's recent but not most recent) I have no startup.pl (just trying to get it to work at this point) Scripts are in /login, and call DBI-connect() and disconnect(). They work, until the connection drops. (Normally, it doesn't time out, but the connection will eventually drop when the network fritzes, figure once or twice a week.) Then I get DBD::Pg::st execute failed: no connection to the server at (my module) in the error log. It looks as if Apache::DBI isn't pinging it, but my efforts to look into have just left me confused...Apache::DBI is loaded, according to Apache::Status, But why won't it log any material? httpd.conf looks like: (test server obviously) MinSpareServers 1 MaxSpareServers 1 StartServers 1 IfModule mod_perl.c PerlTaintCheck On PerlWarn On PerlModule Apache::Status PerlSetVar StatusOptionsAll On PerlSetVar StatusTerse On PerlSetVar StatusTerseSize On PerlSetVar StatusTerseSizeMainSummary On PerlModule B::TerseSize PerlModule Apache::DBI PerlModule Apache::StatINC PerlSetVar StatINC_Debug 1 Location /perl-status SetHandler perl-script PerlHandler Apache::Status /Location Location /login PerlHandler Apache::Registry SetHandler perl-script Options +ExecCGI /Location /IfModule -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: Trouble getting mod_perl and apache running with Apache::DBI
On Sun, 2003-08-17 at 11:41, Perrin Harkins wrote: On Fri, 2003-08-15 at 10:34, K Old wrote: What's happening is that with use Apache::DBI uncommented in either the httpd.conf or startup.pl Apache does not start. Do you have something in your code that connects to a database during startup? That could be a problem. Also, what's the point of use vars qw($dbh %session); in your startup.pl? Do you actually know what package these are being declared in? Probably not one that you will be using later in your scripts. - Perrin Hello everyone, Just wanted to post the solution I ran across so that others have a resource (and when I forget again, I'll have somewhere to look ;) My problem was that I was not declaring PerlModule Apache::DBI in httpd.conf BEFORE my PerlRequire /etc/httpd/conf/startup.pl. Also, I was doing a use Apache::DBI in my startup.pl file, which I shouldn't have done. Hope this helps someone, Kevin -- K Old [EMAIL PROTECTED] -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: Trouble getting mod_perl and apache running with Apache::DBI
On Mon, 2003-08-18 at 11:33, K Old wrote: My problem was that I was not declaring PerlModule Apache::DBI in httpd.conf BEFORE my PerlRequire /etc/httpd/conf/startup.pl. Also, I was doing a use Apache::DBI in my startup.pl file, which I shouldn't have done. Sorry, that is not correct. It's fine to do PerlModule Apache::DBI or do a use Apache::DBI in startup.pl. You should not do both of them, and you should make sure you load Apache::DBI in one of these ways before loading anything that uses DBI. This is all in the Apache::DBI documentation. - Perrin -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Apache::DBI
What's the diference between DBI and Apache::DBI? -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: Apache::DBI
On Mon, 18 Aug 2003, wrote: Date: Mon, 18 Aug 2003 16:57:13 -0700 From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Apache::DBI What's the diference between DBI and Apache::DBI? Have you bothered to read the docs at all? http://search.cpan.org/author/TIMB/DBI-1.37/DBI.pm http://search.cpan.org/author/ABH/Apache-DBI-0.92/DBI.pm ky -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: Trouble getting mod_perl and apache running with Apache::DBI
On Fri, 2003-08-15 at 10:34, K Old wrote: What's happening is that with use Apache::DBI uncommented in either the httpd.conf or startup.pl Apache does not start. Do you have something in your code that connects to a database during startup? That could be a problem. Also, what's the point of use vars qw($dbh %session); in your startup.pl? Do you actually know what package these are being declared in? Probably not one that you will be using later in your scripts. - Perrin -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Trouble getting mod_perl and apache running with Apache::DBI
Hello everyone,
I've set mod_perl up with Apache::DBI on several servers, both with
mod_perl from RPM's and building it myself, but I am having a horrible
time with a new server I've just built. Go easy, I'm still new at it,
though. And I welcome any and all constructive criticism for my config
files, etc.
Here are the specs: RH 7.3, mod_perl 1.2.6 from RPM, Apache::DBI 0.92,
DBI 1.37.
Now, here's what I'm defining in httpd.conf:
snip httpd.conf
IfModule mod_perl.c
Alias /perl /var/www/perl
Directory /var/www/perl
SetHandler perl-script
PerlHandler Apache::Registry
Options +ExecCGI
/Directory
#PerlHandler HTML::Mason::ApacheHandler
PerlSetVar MasonCompRoot /var/www/html/mason
PerlSetVar MasonDataDir /var/mason
PerlSetVar MasonAllowGlobals $dbh
#PerlAddVar MasonAllowGlobals $session
#PerlAddVar MasonAllowGlobals %session
#PerlAddVar MasonAllowGlobals $sys
#PerlSetVar MasonRequestClass MasonX::Request::WithApacheSession
#PerlSetVar MasonSessionClass Apache::Session::File
#PerlSetVar MasonSessionDirectory /tmp/sessions
#PerlSetVar MasonSessionLockDirectory /tmp/sessions
PerlSetEnv DBI_TRACE 3=/tmp/dbitrace.log
PerlRequire /etc/httpd/conf/startup.pl
#PerlModule Apache::DBI
AddType text/html .mhtml
AddType text/html .mason
Location /mason
SetHandler perl-script
PerlHandler HTML::Mason::ApacheHandler
Options +ExecCGI
/Location
/IfModule
/snip httpd.conf
Here's my startup.pl:
snip startup.pl
#!/usr/bin/perl
use warnings;
use strict;
# Extend @INC if needed
#use lib qw(/dir/foo /dir/bar);
use lib qw(/var/www/html/mason/lib);
use lib qw(/var/www/html/mason/hrtime/lib);
use vars qw($dbh %session);
# Make sure we are in a sane environment.
$ENV{MOD_PERL} or die not running under mod_perl!;
# For things in the /perl URL
use Apache::Registry;
#$KO::server_root = /var/www/html/mason/db;
#use KO::DBI::Connect qw(:all);
# Load Perl modules of your choice here
# This code is interpreted *once* when the server starts
use LWP::UserAgent ();
#use Apache::DBI ();
use DBI();
# Tell me more about warnings
use Carp();
$SIG{__WARN__} = \Carp::cluck;
# Load CGI.pm and call its compile() method to precompile
# (but not to import) its autoloaded methods.
use CGI ();
CGI-compile(':all');
# Initialize the database connections for each child
=pod
Apache::DBI-connect_on_init
(DBI:Pg:dbname=auth;host=localhost;port=5432,
root,,
{
PrintError = 1, # warn() on errors
RaiseError = 0, # don't die on error
AutoCommit = 1, # commit executes immediately
}
);
=cut
1;
/snip startup.pl
What's happening is that with use Apache::DBI uncommented in either
the httpd.conf or startup.pl Apache does not start. This is what
error_log reports:
[Thu Aug 14 14:59:49 2003] [notice] Apache/1.3.27 (Unix)
(Red-Hat/Linux) mod_ssl/2.8.7 OpenSSL/0.9.6b DAV/1.0.3 PHP/4.1.2
mod_perl/1.26 mod_throttle/3.1.2 configured -- resuming normal
operations
[Thu Aug 14 14:59:49 2003] [notice] suEXEC mechanism enabled (wrapper:
/usr/sbin/suexec)
[Thu Aug 14 14:59:49 2003] [notice] Accept mutex: sysvsem (Default:
sysvsem)
[Fri Aug 15 10:08:43 2003] [notice] caught SIGTERM, shutting down
When I try to pull up anything the connection is refused (because the
server is down).
I've just been commenting and uncommenting stuff until it worked. The
weird thing is that there are no real error messages from mod_perl in
the apache logs.
Can anyone help?
Thanks,
Kevin
--
K Old [EMAIL PROTECTED]
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
Re: Trouble getting mod_perl and apache running with Apache::DBI
I left out my version of Perl. I'm using 5.6.1 from RPM.
Kevin
On Fri, 2003-08-15 at 10:34, K Old wrote:
Hello everyone,
I've set mod_perl up with Apache::DBI on several servers, both with
mod_perl from RPM's and building it myself, but I am having a horrible
time with a new server I've just built. Go easy, I'm still new at it,
though. And I welcome any and all constructive criticism for my config
files, etc.
Here are the specs: RH 7.3, mod_perl 1.2.6 from RPM, Apache::DBI 0.92,
DBI 1.37.
Now, here's what I'm defining in httpd.conf:
snip httpd.conf
IfModule mod_perl.c
Alias /perl /var/www/perl
Directory /var/www/perl
SetHandler perl-script
PerlHandler Apache::Registry
Options +ExecCGI
/Directory
#PerlHandler HTML::Mason::ApacheHandler
PerlSetVar MasonCompRoot /var/www/html/mason
PerlSetVar MasonDataDir /var/mason
PerlSetVar MasonAllowGlobals $dbh
#PerlAddVar MasonAllowGlobals $session
#PerlAddVar MasonAllowGlobals %session
#PerlAddVar MasonAllowGlobals $sys
#PerlSetVar MasonRequestClass MasonX::Request::WithApacheSession
#PerlSetVar MasonSessionClass Apache::Session::File
#PerlSetVar MasonSessionDirectory /tmp/sessions
#PerlSetVar MasonSessionLockDirectory /tmp/sessions
PerlSetEnv DBI_TRACE 3=/tmp/dbitrace.log
PerlRequire /etc/httpd/conf/startup.pl
#PerlModule Apache::DBI
AddType text/html .mhtml
AddType text/html .mason
Location /mason
SetHandler perl-script
PerlHandler HTML::Mason::ApacheHandler
Options +ExecCGI
/Location
/IfModule
/snip httpd.conf
Here's my startup.pl:
snip startup.pl
#!/usr/bin/perl
use warnings;
use strict;
# Extend @INC if needed
#use lib qw(/dir/foo /dir/bar);
use lib qw(/var/www/html/mason/lib);
use lib qw(/var/www/html/mason/hrtime/lib);
use vars qw($dbh %session);
# Make sure we are in a sane environment.
$ENV{MOD_PERL} or die not running under mod_perl!;
# For things in the /perl URL
use Apache::Registry;
#$KO::server_root = /var/www/html/mason/db;
#use KO::DBI::Connect qw(:all);
# Load Perl modules of your choice here
# This code is interpreted *once* when the server starts
use LWP::UserAgent ();
#use Apache::DBI ();
use DBI();
# Tell me more about warnings
use Carp();
$SIG{__WARN__} = \Carp::cluck;
# Load CGI.pm and call its compile() method to precompile
# (but not to import) its autoloaded methods.
use CGI ();
CGI-compile(':all');
# Initialize the database connections for each child
=pod
Apache::DBI-connect_on_init
(DBI:Pg:dbname=auth;host=localhost;port=5432,
root,,
{
PrintError = 1, # warn() on errors
RaiseError = 0, # don't die on error
AutoCommit = 1, # commit executes immediately
}
);
=cut
1;
/snip startup.pl
What's happening is that with use Apache::DBI uncommented in either
the httpd.conf or startup.pl Apache does not start. This is what
error_log reports:
[Thu Aug 14 14:59:49 2003] [notice] Apache/1.3.27 (Unix)
(Red-Hat/Linux) mod_ssl/2.8.7 OpenSSL/0.9.6b DAV/1.0.3 PHP/4.1.2
mod_perl/1.26 mod_throttle/3.1.2 configured -- resuming normal
operations
[Thu Aug 14 14:59:49 2003] [notice] suEXEC mechanism enabled (wrapper:
/usr/sbin/suexec)
[Thu Aug 14 14:59:49 2003] [notice] Accept mutex: sysvsem (Default:
sysvsem)
[Fri Aug 15 10:08:43 2003] [notice] caught SIGTERM, shutting down
When I try to pull up anything the connection is refused (because the
server is down).
I've just been commenting and uncommenting stuff until it worked. The
weird thing is that there are no real error messages from mod_perl in
the apache logs.
Can anyone help?
Thanks,
Kevin
--
K Old [EMAIL PROTECTED]
--
K Old [EMAIL PROTECTED]
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
Apache::DBI and temporary tables
Hello all, I know from a DBI perspective, when using PostgreSQL, if I create a temporary database table it will automatically go *poof* and be deleted when the database connection is closed (or when the transaction is finished...I can't remember which). Anyway, what will happen if code that takes advantage of this is used in an Apache Registry script? If I do a $dbh-disconnect, I know it will be ignored by Apache::DBI, but is it smart enough to pass something back to the database server telling it that it can purge temporary data? Thanks. -- /* Michael A. Nachbaur [EMAIL PROTECTED] * http://nachbaur.com/pgpkey.asc */ `This must be Thursday,' said Arthur to himself, sinking low over his beer, `I never could get the hang of Thursdays.'
Re: Apache::DBI and temporary tables
On Tue, 2003-07-22 at 17:15, Michael A Nachbaur wrote: If I do a $dbh-disconnect, I know it will be ignored by Apache::DBI, but is it smart enough to pass something back to the database server telling it that it can purge temporary data? No. If you come up with a way to do that, you can add it as a cleanup handler. - Perrin
Re: Apache::DBI and temporary tables
On Tue, 22 Jul 2003 14:15:41 -0700 Michael A Nachbaur [EMAIL PROTECTED] wrote: Hello all, I know from a DBI perspective, when using PostgreSQL, if I create a temporary database table it will automatically go *poof* and be deleted when the database connection is closed (or when the transaction is finished...I can't remember which). Anyway, what will happen if code that takes advantage of this is used in an Apache Registry script? If I do a $dbh-disconnect, I know it will be ignored by Apache::DBI, but is it smart enough to pass something back to the database server telling it that it can purge temporary data? While I'm not 100% sure, I would seriously doubt it since Apache::DBI doesn't call the corresponding DBD's disconnect method. I would do one of the following: 1) Explicitly clean up your temp table. 2) See if you can stop using Apache::DBI. I found on several sites that Apache::DBI didn't effect performance as much as I would have imagined with PostgreSQL and was fine to run without it. - Frank Wiles [EMAIL PROTECTED] http://frank.wiles.org -
[Patch] Apache::DBI - correctly clean up handles and reset attributes
Hi,
Over the past few months I have posted a couple of fixes in relation to how
Apache::DBI handles are cleaned up. This however is the most complete fix in
that it covers the following issues :-
TimeOut = 0 :
Should always ping even when multiple requests are made in
the same secondi
Setting Attributes post connection :
$dbh-{AutoCommit}=0 will convert an AutoCommit handle to non
AutoCommit so when it is next retunred it behaves incorrectly.
Other settings can be effected in the same way.
Using begin_work :
This is a tempory version of the above. The next commit resets
the handle to the default value.
I have tested this under mp1 but do not have any active setups for testing
under mp2. I have not found that this fix degrades performance but I have
not done exhautive benchmarking on multiple platforms. I would be grateful
for all feedback in relation to this patch both good and bad..
The patch is against the current CVS version.
Thank you all
Paddy
--- Changes 2003-07-20 09:03:15.0 +
+++ Changes 2003-07-21 09:02:11.0 +
@@ -1,5 +1,11 @@
Revision history for ApacheDBI.
+patch July 21, 2003
+- Fixed issues relating to chanding handle state post connection.
+ Handles now returned in same state as original and incomplete
+ transactions rolled back before re-issuing handle so begin_work
+ should now be safe. Patrick Mulvany [EMAIL PROTECTED]
+
0.92-dev
- Avoid use of uninitialized value warning under mod_perl 2.
--- DBI.pm 2003-06-10 12:20:06.0 +
+++ DBI.cleanup.pm 2003-07-21 09:22:34.0 +
@@ -23,6 +23,8 @@
my %LastPingTime; # keeps track of last ping per data_source
my $Idx; # key of %Connected and %Rollback.
+# Check to see if we need to reset TaintIn and TaintOut
+my $TaintInOut = ($DBI::VERSION=1.31)?1:0;
# supposed to be called in a startup script.
# stores the data_source of all connections, which are supposed to be created upon
@@ -87,11 +89,13 @@
}
# this PerlCleanupHandler is supposed to initiate a rollback after the script has
finished if AutoCommit is off.
-my $needCleanup = ($Idx =~ /AutoCommit[^\d]+0/) ? 1 : 0;
+# however cleanup can only be determined at end of handle life as begin_work may
have been called to temporarily turn off AutoCommit.
+#
# TODO - Fix mod_perl 2.0 here
-if(!$Rollback{$Idx} and $needCleanup and Apache-can('push_handlers')) {
+if(!$Rollback{$Idx} and Apache-can('push_handlers')) {
print STDERR $prefix push PerlCleanupHandler \n if $Apache::DBI::DEBUG 1;
Apache-push_handlers(PerlCleanupHandler, \cleanup);
+
# make sure, that the rollback is called only once for every
# request, even if the script calls connect more than once
$Rollback{$Idx} = 1;
@@ -101,7 +105,8 @@
$PingTimeOut{$dsn} = 0 unless $PingTimeOut{$dsn};
$LastPingTime{$dsn} = 0 unless $LastPingTime{$dsn};
my $now = time;
-my $needping = (($PingTimeOut{$dsn} == 0 or $PingTimeOut{$dsn} 0) and $now -
$LastPingTime{$dsn} $PingTimeOut{$dsn}) ? 1 : 0;
+# Must ping if TimeOut = 0 else base on time
+my $needping = ($PingTimeOut{$dsn} == 0 or ($PingTimeOut{$dsn} 0 and $now -
$LastPingTime{$dsn} $PingTimeOut{$dsn})) ? 1 : 0;
print STDERR $prefix need ping: , $needping == 1 ? yes : no, \n if
$Apache::DBI::DEBUG 1;
$LastPingTime{$dsn} = $now;
@@ -112,6 +117,10 @@
# RaiseError being on and the handle is invalid.
if ($Connected{$Idx} and (!$needping or eval{$Connected{$Idx}-ping})) {
print STDERR $prefix already connected to '$Idx'\n if $Apache::DBI::DEBUG
1;
+
+# Force clean up of handle in case previous transaction failed to clean up
the handle
+reset_startup_state();
+
return (bless $Connected{$Idx}, 'Apache::DBI::db');
}
@@ -121,6 +130,9 @@
$Connected{$Idx} = $drh-connect(@args);
return undef if !$Connected{$Idx};
+# store the parameters of the initial connection in the handle
+set_startup_state($Connected{$Idx});
+
# return the new database handle
print STDERR $prefix new connect to '$Idx'\n if $Apache::DBI::DEBUG;
return (bless $Connected{$Idx}, 'Apache::DBI::db');
@@ -158,6 +170,47 @@
1;
}
+# Store the default start state of each dbh in the handle
+# Note: This uses private_Apache_DBI hash ref to store it in the handle itself
+
+sub set_startup_state {
+foreach my $key qw{ AutoCommit Warn CompatMode InactiveDestroy
+PrintError RaiseError HandleError
+ShowErrorStatement TraceLevel FetchHashKeyName
+ChopBlanks LongReadLen LongTruncOk
+Taint Profile} {
+$Connected{$Idx}-{private_Apache_DBI}{$key} = $Connected{$Idx
Re: [mp2] Apache::DBI
Beau E. Cox wrote: Hi - I am running Apache 2.0.47/mod_perl 1.99-dev-10-cvs on SuSE Linux 8.2. I am trying to install and use Apache::DBI. [...] 2) The documentation says to configure mod_perl with: perl Makefile.PL PERL_CHILD_INIT=1 PERL_AUTHEN=1 PERL_AUTHZ=1 PERL_CLEANUP=1 PERL_STACKED_HANDLERS=1 These are mod_perl 1 parameters. I could not find any corresponding mod_perl 2 parameters. That documentation is talking about mod_perl 1.0, mod_perl 2.0 doesn't need any of these compile options. which URL you are talking about? Perhaps it should be fixed to say that you need these options only if you use mp1. __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
[mp2] Apache::DBI
Hi - I am running Apache 2.0.47/mod_perl 1.99-dev-10-cvs on SuSE Linux 8.2. I am trying to install and use Apache::DBI. 1) I get this error in make test: is($thread_1, $thread_2, got the same connection both times); It seems the I do not get the same connection. 2) The documentation says to configure mod_perl with: perl Makefile.PL PERL_CHILD_INIT=1 PERL_AUTHEN=1 PERL_AUTHZ=1 PERL_CLEANUP=1 PERL_STACKED_HANDLERS=1 These are mod_perl 1 parameters. I could not find any corresponding mod_perl 2 parameters. 3) ADBI Changes states: 0.90_02 January 10, 2003 - Changes to make Apache::DBI load and function under mod_perl 2.0. A few important notes: connect_on_init does not work yet... Should I use 'connect' in my startup.pl? Have any of you sucessfully installed and used ADBI under mod_perl 2? Any advice on what I'm missing? Aloha = Beau;
Re: [mp2] Apache::DBI
On Yesterday at 10:01pm, BEC=Beau E. Cox [EMAIL PROTECTED] wrote:
BEC
BECShould I use 'connect' in my startup.pl?
BEC
BEC Have any of you sucessfully installed and used ADBI under
BEC mod_perl 2? Any advice on what I'm missing?
BEC
Hi Beau,
I'm using apache 2.0.46, mod_perl 1.9909, perl v5.8.0, Apache::DBI 0.91 on
a Gentoo kernel 2.4.20-ck6 without any problems in production. I have had
no problems with using connect_on_init either. I have:
use Apache::compat ();
as my first use statement in my mod_perl startup.pl file.
Further down the script, I have:
use Apache::DBI;
DBI-install_driver(mysql);
Apache::DBI-connect_on_init(..fill in here..);
If I set $Apache::DBI::DEBUG = 2 in my startup file I do see connects on
init as the new apaches come up. Of course, I commented out that line when
in production.
Dunno about how to track your make test problems. Now that you know that
someone has it working, you can retrace your steps and see if you missed
something.
I do however use this patch which is in cvs for Apache::DBI which skips
use of uninitialized variable warnings upon server startup.
--- DBI.pm 17 Feb 2003 13:04:19 - 1.6
+++ DBI.pm 4 Apr 2003 10:58:53 - 1.7
@@ -81,7 +81,7 @@
# won't be useful after ChildInit, since multiple processes trying to
# work over the same database connection simultaneously will receive
# unpredictable query results.
-if ($Apache::ServerStarting == 1) {
+if ($Apache::ServerStarting and $Apache::ServerStarting == 1) {
print STDERR $prefix skipping connection during server startup,
read the docu !!\n if $Apache::DBI::DEBUG 1;
return $drh-connect(@args);
}
Good luck,
--
Haroon Rafique
[EMAIL PROTECTED]
Re: [mp2] Apache::DBI
- Original Message - From: Haroon Rafique [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, July 14, 2003 3:23 AM Subject: Re: [mp2] Apache::DBI On Yesterday at 10:01pm, BEC=Beau E. Cox [EMAIL PROTECTED] wrote: BEC BECShould I use 'connect' in my startup.pl? BEC BEC Have any of you sucessfully installed and used ADBI under BEC mod_perl 2? Any advice on what I'm missing? BEC Hi Beau, I'm using apache 2.0.46, mod_perl 1.9909, perl v5.8.0, Apache::DBI 0.91 on a Gentoo kernel 2.4.20-ck6 without any problems in production. I have had no problems with using connect_on_init either. I have: [snip] Haroon Rafique [EMAIL PROTECTED] Haroon - What a great reply; wonderfully mapped out, all set to go! I will proceed to install and use ADBI. Aloha = Beau; == please visit == http://beaucox.com = main site http://howtos.beaucox.com = howtos http://PPM.beaucox.com = perl PPMs http://CPAN.beaucox.com = CPAN == thank you ==
[PATCH] Apache::DBI - AutoCommit = 1 and begin_work (inc example)
Hi,
Came accross a bug when when trying to reduce creation of handles on a site.
Currently Apache::DBI makes the assumption that it AutoCommit = 1 then the handle
does not need cleaning up. This is not neccessariliy true as begin_work switches off
the AutoCommit for one transaction.
First time the handle is used AutoCommit=1 and a transaction is started with
begin_work but the script fails to call either commit or rollback for any reason (ie
dies) causing an incomplete transaction to exist.
Next time Apache::DBI returns the handle it is still mid transaction and but thinks
AutoCommit is on which it is not. You therefor end up with following scripts thinking
every DBI action is auto commited but it is not. Locks develop on the updated tables
which becomes very messy when not running single process mode.
Usually the only way to remove these locks is by killing the Apache process.
On Oracle the test script uses this table in the scott/tiger schema the bug should
apply to any DB that impliments transaction but I have only tested against Oracle :-
create table T (A number(20));
When the test script is run with test.cgi?commit=0 then the final transaction is not
commited :-
SQL truncate table T;
truncate table T
*
ERROR at line 1:
ORA-00054: resource busy and acquire with NOWAIT specified
But with test.cgi?commit=1 then the last transactio is committed or then the patch
applied then it rolls back and this works:-
SQL truncate table T;
Table truncated.
Please find attached the example script and the patch against CVS v1.7.
Thank you
Paddy
#!/usr/bin/perl
use strict;
use CGI;
use DBI;
use Data::Dumper;
my $cgi = new CGI();
print $cgi-header();
# Apache::DBI test code
my $DBI_CONNECT= dbi:Oracle:host=xx.xx.xx.xx;sid=;
my $dbh = DBI-connect($DBI_CONNECT,'scott','tiger');
my $query1 = 'select A from T';
my $sth = $dbh-prepare($query1);
$sth-execute();
print h1Test Results/h1\n;
print 'pre'.Dumper($sth-fetchall_arrayref)./pre\n;
my $before = $dbh-{AutoCommit};
$dbh-begin_work();
my $after = $dbh-{AutoCommit};
my $query2 = 'insert into T (A) values (?)';
my $sth2 = $dbh-prepare($query2);
print h1Test Error Trans/h1\n;
my $time1=time;
print This should commit $time1\n;
$sth2-execute($time1);
$dbh-commit();
print h1Test Error Trans/h1\n;
$dbh-begin_work();
my $time2=time+10;
print This should roll back $time2\n if (!$cgi-param('commit'));
$sth2-execute($time2);
$dbh-commit() if ($cgi-param('commit'));
1;
--- DBI/DBI.pm 2003-06-10 12:20:06.0 +
+++ DBI/DBI.pm 2003-06-10 12:42:07.0 +
@@ -87,9 +87,10 @@
}
# this PerlCleanupHandler is supposed to initiate a rollback after the script has
finished if AutoCommit is off.
-my $needCleanup = ($Idx =~ /AutoCommit[^\d]+0/) ? 1 : 0;
+# however cleanup can only be determined at end of handle life as begin_work may
have been called to temporarily turn off AutoCommit.
+#
# TODO - Fix mod_perl 2.0 here
-if(!$Rollback{$Idx} and $needCleanup and Apache-can('push_handlers')) {
+if(!$Rollback{$Idx} and Apache-can('push_handlers')) {
print STDERR $prefix push PerlCleanupHandler \n if $Apache::DBI::DEBUG 1;
Apache-push_handlers(PerlCleanupHandler, \cleanup);
# make sure, that the rollback is called only once for every
pgp0.pgp
Description: PGP signature
Re: [mp2] win2000 + Apache::DBI + Oracle
On Tue, 2003-06-10 at 01:45, Stas Bekman wrote: mp2+winFU = winnt MPM = no forking, only threads = Apache::DBI is useless there. not only useless, but also wasteful, since it's going to do work that has no added value. But how is this any different from separate processes really? Each thread is a separate interpreter with separate globals and this separate Apache::DBI persistent handles. If things are not threadsafe it crashes, but if they are it should work just like it does for multi-process apache, shouldn't it? - Perrin
Re: [mp2] win2000 + Apache::DBI + Oracle
Perrin Harkins wrote: On Tue, 2003-06-10 at 01:45, Stas Bekman wrote: mp2+winFU = winnt MPM = no forking, only threads = Apache::DBI is useless there. not only useless, but also wasteful, since it's going to do work that has no added value. But how is this any different from separate processes really? Each thread is a separate interpreter with separate globals and this separate Apache::DBI persistent handles. If things are not threadsafe it crashes, but if they are it should work just like it does for multi-process apache, shouldn't it? I think you are right. I was thinking about pooling across threads. If somebody can give it a try and report back (use debug mode to see what happens) that would be the simplest check. connect_on_init() should probably be not used. __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: [mp2] win2000 + Apache::DBI + Oracle
On Tue, Jun 10, 2003 at 04:27:17PM +1000, Stas Bekman wrote: Perrin Harkins wrote: On Tue, 2003-06-10 at 01:45, Stas Bekman wrote: mp2+winFU = winnt MPM = no forking, only threads = Apache::DBI is useless there. not only useless, but also wasteful, since it's going to do work that has no added value. But how is this any different from separate processes really? Each thread is a separate interpreter with separate globals and this separate Apache::DBI persistent handles. If things are not threadsafe it crashes, but if they are it should work just like it does for multi-process apache, shouldn't it? I think you are right. I was thinking about pooling across threads. If somebody can give it a try and report back (use debug mode to see what happens) that would be the simplest check. connect_on_init() should probably be not used. connect_on_init() pushs to a list of connection strings to start on child creation. childinit should be called as a PerlChildInitHandler (not sure when MP2 handles these) but is this called per thread? Note to me: Fix issue of cleanup not correctly rolling back when an AutoCommit in on but begin_work has been called. Could be causing side effects in following reuse of handle. Similar issues may exist with overriding other default parameters from within a handle. my $needCleanup = ($Idx =~ /AutoCommit[^\d]+0/) ? 1 : 0; looks like being the offending line. I will extend my handle limiting patch to cover this and resubmit to here. Hope it helps Paddy pgp0.pgp Description: PGP signature
Re: [mp2] win2000 + Apache::DBI + Oracle
Patrick Mulvany wrote: On Tue, Jun 10, 2003 at 04:27:17PM +1000, Stas Bekman wrote: connect_on_init() should probably be not used. connect_on_init() pushs to a list of connection strings to start on child creation. childinit should be called as a PerlChildInitHandler (not sure when MP2 handles these) but is this called per thread? No, PerlChildInitHandler is called when a process starts up. Apache provides no hooks for threads startup. http://perl.apache.org/docs/2.0/user/handlers/server.html#PerlChildInitHandler __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
[mp2] win2000 + Apache::DBI + Oracle
So, according to the docs, http://perl.apache.org/docs/2.0/user/performance/mpm.html#Work_with_DataBases_under_Threaded_MPM, using Apache::DBI doesn't do anything under mp2+windows2000 ... What is the status of DBI::Pool? These modules deal mainly with persistent database connections. Is that correct? Paul
Re: [mp2] win2000 + Apache::DBI + Oracle
Paul Simon wrote: So, according to the docs, http://perl.apache.org/docs/2.0/user/performance/mpm.html#Work_with_DataBases_under_Threaded_MPM, using Apache::DBI doesn't do anything under mp2+windows2000 ... That's correct. Since Apache::DBI does per-process pooling, and apache 2.0 on winFU, runs one process with many threads. So Apache::DBI is useless there. What is the status of DBI::Pool? I've posted a hard-coded mysql prototype to the dbi-dev list a few months ago. Tim has added the required DBI support recently, but I haven't had a chance to do any work on it since then. If you or anybody else is interested in helping to code DBI::Pool let me know. These modules deal mainly with persistent database connections. Is that correct? That's correct. But since you are using Oracle, if I remember correctly DBD::Oracle provides an internal pooling support. I could be wrong, please check the docs. __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: [mp2] win2000 + Apache::DBI + Oracle
On Mon, 2003-06-09 at 21:02, Stas Bekman wrote: Paul Simon wrote: So, according to the docs, http://perl.apache.org/docs/2.0/user/performance/mpm.html#Work_with_DataBases_under_Threaded_MPM, using Apache::DBI doesn't do anything under mp2+windows2000 ... That's correct. Since Apache::DBI does per-process pooling, and apache 2.0 on winFU, runs one process with many threads. So Apache::DBI is useless there. Wait a minute, it's only useless if DBI and DBD::Oracle are not thread safe. Do we know if that's true? Just to be clear, Apache::DBI stores database handles in globals, which are not shared between threads. This provides persistence. DBI::Pool is a more ambitious idea to allow the handles to be actually shared, providing pooling as well as persistence. But since you are using Oracle, if I remember correctly DBD::Oracle provides an internal pooling support. I could be wrong, please check the docs. It's called ora_dbh_share. I haven't tried it yet, and probably won't for a bit since I'm not using Oracle at the moment. - Perrin
Re: [mp2] win2000 + Apache::DBI + Oracle
Perrin Harkins wrote: On Mon, 2003-06-09 at 21:02, Stas Bekman wrote: Paul Simon wrote: So, according to the docs, http://perl.apache.org/docs/2.0/user/performance/mpm.html#Work_with_DataBases_under_Threaded_MPM, using Apache::DBI doesn't do anything under mp2+windows2000 ... That's correct. Since Apache::DBI does per-process pooling, and apache 2.0 on winFU, runs one process with many threads. So Apache::DBI is useless there. Wait a minute, it's only useless if DBI and DBD::Oracle are not thread safe. Do we know if that's true? Yes, but: mp2+winFU = winnt MPM = no forking, only threads = Apache::DBI is useless there. not only useless, but also wasteful, since it's going to do work that has no added value. Of course I tell all that without ever using winFU, but I don't think this is a wrong assumption if the server doesn't fork. Just to be clear, Apache::DBI stores database handles in globals, which are not shared between threads. This provides persistence. DBI::Pool is a more ambitious idea to allow the handles to be actually shared, providing pooling as well as persistence. Once DBI::Pool will be available, Apache::DBI may use it internally, or it may become obsolete altogether. But since you are using Oracle, if I remember correctly DBD::Oracle provides an internal pooling support. I could be wrong, please check the docs. It's called ora_dbh_share. I haven't tried it yet, and probably won't for a bit since I'm not using Oracle at the moment. __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
[patch] Apache::DBI can't be made to always ping
We've been having some problems with our Oracle 8.1.5 database on AIX, which has
highlighted what looks like a problem with Apache::DBI. To cut a very long story
short, due to an Oracle problem database handles are becoming invalid reasonably
frequently. In this case, we would expect Apache::DBI to ping on each connect
request as the ping timeout is set to zero. However, it has been returning dead
handles. Enabling the trace feature showed that it did not always ping, the
problem being that if there is a request for a handle within one second, even if
the ping timeout is zero it will not ping.
A patch for this follows, it is simply a matter of changing the time test from a
to a = in line 103 of version 0.88:
my $needping = (($PingTimeOut{$dsn} == 0 or $PingTimeOut{$dsn} 0) and $now -
$LastPingTime{$dsn} = PingTimeOut{$dsn}) ? 1 : 0;
So far as I can tell this still applies to the most recent version. I would like
to ask the maintainer of this module if this patch or equivalent fix could be
included in the next release of the module.
Apologies if this message is posted to the wrong place, I think I got it
right...
Regards
Dennis Ingram
**
This email with any attachments is confidential and may be
subject to legal privilege. If it is not intended for you please
reply immediately, destroy it and do not copy, disclose or use
it in any way.
**
Re: [OT] Apache::DBI and Postgres
On Wed, May 14, 2003 at 10:48:45AM -0400, Eric Sammer wrote:
Not really a problem (yet), but out of curiousity...
I'm using Apache::DBI with postgres and while not serving requests, all
the postgres processes are listed as idle in transaction. Obviously,
the DBI connect statements are configured with AutoCommit = 0. It
doesn't seem to cause any real problems, but it does concern me that
postgres considers itself in a transaction with only a connect (i.e.
prior to a $dbh-prepare()). I threw some SELECTs at it and it's fine,
but I worry about transaction blocking under heavier load and with
INSERT, DELETE, and UPDATE statements. ...or maybe I'm just thinking too
Oracle-ish about it.
I noticed an interesting problem with regards to dates and times. If
you have columns that you let pgsql fill in, frex:
Column |Type | Modifiers
--+-+---
order_date | date| default date('now'::text)
order_time | time with time zone | default ('now'::text)::time(6) with time zone
Those dates and times will tend to be off, because pgsql uses the
exact date/time at the _start_ of the transaction. And with Apache::DBI
the transaction could have been started quite some time ago, unless your
server is heavily loaded and/or you do lots of SELECT queries before
adding new rows (thus making sure you end up with a relatively fresh
transaction).
Just to illustrate this, I first get the current time on my server:
dev= SELECT current_time;
timetz
20:11:20.787832-04
Then I go to my mod_perl application and add a new account. The
resulting row has:
order_date | order_time
+
2003-06-01 | 20:10:46.349862-04
And order_time in this row is chronologically before, even though I
added the account _after_ typing 'SELECT current_time' in my psql
console...
The date can be off too, if Apache::DBI used an old, stale transaction
that started the previous day (this is very possible if a new record is
added alightly after midnight...)
Re: [mp2] Using DBI instead of Apache::DBI
[please keep the threads on the list unless requested otherwise]
Georg Botorog wrote:
Thanks. But I still have not understood how I avoid to include
Apache::DBI in the current version of Apache (2). In mp1, there was an
explicit inclusion statement in httpd.conf, which I could leave out. I
have found nothing of the kind in mp2. Still, Apache::DBI is loaded.
Maybe I have not expressed clearly: I do not want to unimport an
included module, I simply do not want to include a special module,
Apache::DBI, at all in a certain instance of Apache.
What you are saying is that you don't load Apache::DBI, but something else
does, right?
Install this override at the very beginning of your startup.pl and watch the
logs to see who loads Apache::DBI.
*CORE::GLOBAL::require = sub {
warn require $_[0]\n;
CORE::require(@_)
};
This should work with 5.6.x, not sure about earlier perl versions.
-Original Message-
From: Stas Bekman [SMTP:[EMAIL PROTECTED]
Sent: Tuesday, March 11, 2003 11:55 PM
To: Georg Botorog
Cc: [EMAIL PROTECTED]
Subject:Re: [mp2] Using DBI instead of Apache::DBI
Georg Botorog wrote:
Hello,
In mod_perl1, using persistent (Apache::DBI) and dedicated, per-user
connections (DBI) on the same machine required running two Apache
instances, one with Apache::DBI and the other without it.
Has anything about that changed in mod_perl2?
Moreover, how does Apache2 know it has to load Apache::DBI? There is
no PerlModule Apache::DBI statement in my httpd.conf (as it was
under mp1), neither a use Apache::DBI in startup.pl or in any
other
module. Or, to put it the other way around: how can I avoid
including
Apache::DBI (in the DBI-only instance)?
As you said Apache::DBI is either on or off and it will work just the
same
under mp2 as it does under mp1.
However in the near future DBI is going to support pooling internally,
which
will take the benefit of threads if available.
And I think it could be made more flexible than Apache::DBI, i.e. too
be more
than just on or off. I think Apache::DBI can do the same. What we
really need
is some sort of pragma where you can control Apache::DBI. e.g. let's
say that
once you load Apache::DBI it turns the pooling on globally. But than
in your
script you should be able to say (you can't do it just yet):
no Apache::DBI; # which calls Apache::DBI::unimport
$dbh = DBI-connect(...)
and the unimport will restore the default DBI behavior for the scope
of that
pragma (e.g. handler) and restores to the previous behavior on the
scope exit.
Similar to how the warnings pragma works.
It's be nice to have a generic pragma for turning any functionality on
and off
(do we have one already?). e.g. let's call it 'override':
use override 'Apache::DBI';
# Apache::DBI overrides DBI here
no override 'Apache::DBI';
# the previous functionality is restored (e.g. back to DBI)
__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
--
__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
[mp2] Using DBI instead of Apache::DBI
Hello, In mod_perl1, using persistent (Apache::DBI) and dedicated, per-user connections (DBI) on the same machine required running two Apache instances, one with Apache::DBI and the other without it. Has anything about that changed in mod_perl2? Moreover, how does Apache2 know it has to load Apache::DBI? There is no PerlModule Apache::DBI statement in my httpd.conf (as it was under mp1), neither a use Apache::DBI in startup.pl or in any other module. Or, to put it the other way around: how can I avoid including Apache::DBI (in the DBI-only instance)? Thanks George
Re: [mp2] Using DBI instead of Apache::DBI
Georg Botorog wrote: Hello, In mod_perl1, using persistent (Apache::DBI) and dedicated, per-user connections (DBI) on the same machine required running two Apache instances, one with Apache::DBI and the other without it. Has anything about that changed in mod_perl2? Moreover, how does Apache2 know it has to load Apache::DBI? There is no PerlModule Apache::DBI statement in my httpd.conf (as it was under mp1), neither a use Apache::DBI in startup.pl or in any other module. Or, to put it the other way around: how can I avoid including Apache::DBI (in the DBI-only instance)? As you said Apache::DBI is either on or off and it will work just the same under mp2 as it does under mp1. However in the near future DBI is going to support pooling internally, which will take the benefit of threads if available. And I think it could be made more flexible than Apache::DBI, i.e. too be more than just on or off. I think Apache::DBI can do the same. What we really need is some sort of pragma where you can control Apache::DBI. e.g. let's say that once you load Apache::DBI it turns the pooling on globally. But than in your script you should be able to say (you can't do it just yet): no Apache::DBI; # which calls Apache::DBI::unimport $dbh = DBI-connect(...) and the unimport will restore the default DBI behavior for the scope of that pragma (e.g. handler) and restores to the previous behavior on the scope exit. Similar to how the warnings pragma works. It's be nice to have a generic pragma for turning any functionality on and off (do we have one already?). e.g. let's call it 'override': use override 'Apache::DBI'; # Apache::DBI overrides DBI here no override 'Apache::DBI'; # the previous functionality is restored (e.g. back to DBI) __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Apache::DBI on mp2
On Thu, 6 Mar 2003, Stas Bekman wrote: re: rollback, the DBD drivers will perform the normal disconnect(), but without doing the physical disconnect, and normal DESTROY, without destroying the datastructures which maintain the physical connection, so there shouldn't be much to change for this feature. If the physical connection is still there, would the database server do a rollback? - ask ps. yes, your DBI::Pool work is great. Thank you. :-) -- ask bjoern hansen, http://www.askbjoernhansen.com/ !try; do();
Re: Apache::DBI on mp2
Ask Bjoern Hansen wrote: On Thu, 6 Mar 2003, Stas Bekman wrote: re: rollback, the DBD drivers will perform the normal disconnect(), but without doing the physical disconnect, and normal DESTROY, without destroying the datastructures which maintain the physical connection, so there shouldn't be much to change for this feature. If the physical connection is still there, would the database server do a rollback? If earlier the rollback worked correctly with $dbh ||= connect();, this will work the same, since it performs the same operation, but rips off only parts of $dbh, because of the constraints of sharing Perl datastructures and underlying C structs. ps. yes, your DBI::Pool work is great. Thank you. :-) My pleasure. Thanks for the kind words. It's quite challenging, though you stop getting excited about segfaults and ddd (gdb frontend) is nowadays my best friend ;) __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Apache::DBI on mp2
On Fri, 7 Mar 2003, Stas Bekman wrote: If the physical connection is still there, would the database server do a rollback? If earlier the rollback worked correctly with $dbh ||= connect();, this will work the same, since it performs the same operation, but rips off only parts of $dbh, because of the constraints of sharing Perl datastructures and underlying C structs. Apache::DBI explicitly calls $dbh-rollback (when things are configured so it makes sense). Or maybe I am completely misunderstanding you. ps. yes, your DBI::Pool work is great. Thank you. :-) My pleasure. Thanks for the kind words. It's quite challenging, though you stop getting excited about segfaults and ddd (gdb frontend) is nowadays my best friend ;) :-) You are quite the masochist if you ever got excited about segfaults. I only recall segfaults making me slam my head into the wall to conceal the pain. - ask -- ask bjoern hansen, http://www.askbjoernhansen.com/ !try; do();
Re: Apache::DBI on mp2
Ask Bjoern Hansen wrote: On Fri, 7 Mar 2003, Stas Bekman wrote: If the physical connection is still there, would the database server do a rollback? If earlier the rollback worked correctly with $dbh ||= connect();, this will work the same, since it performs the same operation, but rips off only parts of $dbh, because of the constraints of sharing Perl datastructures and underlying C structs. Apache::DBI explicitly calls $dbh-rollback (when things are configured so it makes sense). Or maybe I am completely misunderstanding you. All I was saying is, that whatever worked for Apache::DBI will work for internal pooling. ps. yes, your DBI::Pool work is great. Thank you. :-) My pleasure. Thanks for the kind words. It's quite challenging, though you stop getting excited about segfaults and ddd (gdb frontend) is nowadays my best friend ;) :-) You are quite the masochist if you ever got excited about segfaults. I only recall segfaults making me slam my head into the wall to conceal the pain. I meant in the way that when something is repeated too many times it's not the same anymore ;) so s/excited/annoyed/ will do ;) __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Apache::DBI on mp2
On Wed, 5 Mar 2003, Stas Bekman wrote: Great. I've already committed that patch. Perhaps Ask could load 'Apache::compat' inside Apache::DBI if mp2 is used. Or to use the mp2 API if mp2 is used. That seems like it'll be an easy solution. I thought loading Apache::compat would have global side effects though? (i.e. for people trying to make their system run without Apache::compat). - ask -- ask bjoern hansen, http://www.askbjoernhansen.com/ !try; do();
Re: Apache::DBI on mp2
Ask Bjoern Hansen wrote: On Wed, 5 Mar 2003, Stas Bekman wrote: Great. I've already committed that patch. Perhaps Ask could load 'Apache::compat' inside Apache::DBI if mp2 is used. Or to use the mp2 API if mp2 is used. That seems like it'll be an easy solution. I thought loading Apache::compat would have global side effects though? (i.e. for people trying to make their system run without Apache::compat). Please scratch that idea than ;) Though it can be documented, including the Apache::compat warning ;) And instead simply add the code to handle it differently if $mod_perl::VERSION = 1.99, using the 2.0 API. __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Apache::DBI on mp2
Stas Bekman wrote: FWIW, we are discussing the internal DBI pooling mechanism at the dbi-dev list and having already a sort-of-working prototype. So hopefully there will be no need for Apache::DBI in the near future, as DBI will be able to handle pooling internally. However it may take some time, as the drivers will have to adjust to support the new functionality. You can see the thread here: http://archive.develooper.com/[EMAIL PROTECTED]/index.html#02118 Some working examples are attached to this message: http://archive.develooper.com/[EMAIL PROTECTED]/msg02134.html This is totally cool, Stas! Nice work. I look forward to answering yes when people ask if mod_perl has database connections pooling. By the way, to completely get rid of Apache::DBI this would need to cover the safety functionality in there as well, i.e. the pinging and the part where it rolls back any pending transactions when a a handle is returned to the pool. - Perrin
Re: Apache::DBI on mp2
Perrin Harkins wrote: Stas Bekman wrote: FWIW, we are discussing the internal DBI pooling mechanism at the dbi-dev list and having already a sort-of-working prototype. So hopefully there will be no need for Apache::DBI in the near future, as DBI will be able to handle pooling internally. However it may take some time, as the drivers will have to adjust to support the new functionality. You can see the thread here: http://archive.develooper.com/[EMAIL PROTECTED]/index.html#02118 Some working examples are attached to this message: http://archive.develooper.com/[EMAIL PROTECTED]/msg02134.html This is totally cool, Stas! Nice work. I look forward to answering yes when people ask if mod_perl has database connections pooling. ;) actually it's going to be: if perl has database connections pooling, which will include mod_perl by definition. Also, the pooling mechanism should work transparently w/ and w/o threads on the user level. By the way, to completely get rid of Apache::DBI this would need to cover the safety functionality in there as well, i.e. the pinging and the part where it rolls back any pending transactions when a a handle is returned to the pool. Certainly. Quite a few features are missing. The first step was (is) to make the dbh shared between threads (which is far from trivial). The rest should be just a matter of coding. re: rollback, the DBD drivers will perform the normal disconnect(), but without doing the physical disconnect, and normal DESTROY, without destroying the datastructures which maintain the physical connection, so there shouldn't be much to change for this feature. Only the ping() is needed to be added to connect(). __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Apache::DBI on mp2
On Today at 11:16am, SB=Stas Bekman [EMAIL PROTECTED] wrote: SB FWIW, we are discussing the internal DBI pooling mechanism at the SB dbi-dev list and having already a sort-of-working prototype. So SB hopefully there will be no need for Apache::DBI in the near future, as SB DBI will be able to handle pooling internally. However it may take SB some time, as the drivers will have to adjust to support the new SB functionality. SB SB You can see the thread here: SB http://archive.develooper.com/[EMAIL PROTECTED]/index.html#02118 SB SB Some working examples are attached to this message: SB http://archive.develooper.com/[EMAIL PROTECTED]/msg02134.html SB Stas, Thanks for your response. I will try and keep up with the developments in the above-mentioned threads. However, for now, I'll focus on your alternate solution as mentioned below. If I find some free time (what are the chances?) I may also give DBI::Pool a try under mp2. SB [..snip..] SB SB If you apply the following patch (will commit it soon) against the modperl-2.0 SB source, you will be able to use connect_on_init unmodified, assuming that SB Apache::compat was loaded before Apache::DBI. Let me know whether it works for SB you. SB I'm happy to report that the patch to lib/Apache/compat.pm works. I did not even have to use CVS versions of any of the packages. Apache/2.0.44 (Gentoo/Linux) mod_perl/1.99_08 Perl/v5.8.0 I simply patched: /usr/lib/perl5/vendor_perl/5.8.0/i686-linux/Apache2/Apache/compat.pm with your patch and connect_on_init works unmodified. And as mentioned in your email, I do have Apache::compat loaded before Apache::DBI. Cheers, -- Haroon Rafique [EMAIL PROTECTED]
Re: Apache::DBI on mp2
Haroon Rafique wrote: On Today at 11:16am, SB=Stas Bekman [EMAIL PROTECTED] wrote: SB FWIW, we are discussing the internal DBI pooling mechanism at the SB dbi-dev list and having already a sort-of-working prototype. So SB hopefully there will be no need for Apache::DBI in the near future, as SB DBI will be able to handle pooling internally. However it may take SB some time, as the drivers will have to adjust to support the new SB functionality. SB SB You can see the thread here: SB http://archive.develooper.com/[EMAIL PROTECTED]/index.html#02118 SB SB Some working examples are attached to this message: SB http://archive.develooper.com/[EMAIL PROTECTED]/msg02134.html SB Stas, Thanks for your response. I will try and keep up with the developments in the above-mentioned threads. However, for now, I'll focus on your alternate solution as mentioned below. If I find some free time (what are the chances?) I may also give DBI::Pool a try under mp2. I've already tried it and it works ;) However DBI::Pool won't have a life on its own and will be integrated into DBI itself and its DBD drivers. SB [..snip..] SB SB If you apply the following patch (will commit it soon) against the modperl-2.0 SB source, you will be able to use connect_on_init unmodified, assuming that SB Apache::compat was loaded before Apache::DBI. Let me know whether it works for SB you. SB I'm happy to report that the patch to lib/Apache/compat.pm works. I did not even have to use CVS versions of any of the packages. Apache/2.0.44 (Gentoo/Linux) mod_perl/1.99_08 Perl/v5.8.0 I simply patched: /usr/lib/perl5/vendor_perl/5.8.0/i686-linux/Apache2/Apache/compat.pm with your patch and connect_on_init works unmodified. And as mentioned in your email, I do have Apache::compat loaded before Apache::DBI. Great. I've already committed that patch. Perhaps Ask could load 'Apache::compat' inside Apache::DBI if mp2 is used. Or to use the mp2 API if mp2 is used. __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Apache::DBI on mp2
My setup is as follows:
Apache/2.0.44 (Gentoo/Linux) mod_perl/1.99_08 Perl/v5.8.0
mod_perl was built from CVS.
I was interested in getting Apache::DBI to run under mp2. I did read
Ask's message at
http://marc.theaimsgroup.com/?l=apache-modperlm=104225578207460w=2
which leads me to my question. What would it take to get connect_on_init
to run under mp2?
With the following patch I was able to get connect_on_init to work under
mp2. Remember that my objective was to JUST get it to run. This is NOT
release quality code. I'm happy to report that it works for me, so far.
Anyone else who is running mp2 (no compat mode) willing to give it a try?
Of course, then the gurus can come in and clean up the code so that it
works under either mp1 or mp2.
diff -u DBI.pm /usr/lib/perl5/site_perl/5.8.0/Apache/DBI.pm
--- DBI.pm 2003-02-17 08:04:19.0 -0500
+++ /usr/lib/perl5/site_perl/5.8.0/Apache/DBI.pm2003-03-03
12:03:06.0 -0500
@@ -7,6 +7,8 @@
use DBI ();
use Carp qw(carp);
+use Apache::ServerUtil ();
+
require_version DBI 1.00;
$Apache::DBI::VERSION = '0.91';
@@ -32,9 +34,8 @@
# provide a handler which creates all connections during server
startup
# TODO - Should check for mod_perl 2 and do the right thing there
-carp Apache.pm was not loaded\n and return unless
$INC{'Apache.pm'};
-if([EMAIL PROTECTED] and Apache-can('push_handlers')) {
-Apache-push_handlers(PerlChildInitHandler = \childinit);
+if([EMAIL PROTECTED]) {
+Apache-server-push_handlers(PerlChildInitHandler =
\childinit);
}
# store connections
push @ChildConnect, [EMAIL PROTECTED];
@@ -89,9 +90,9 @@
# this PerlCleanupHandler is supposed to initiate a rollback after
the script has finished if AutoCommit is off.
my $needCleanup = ($Idx =~ /AutoCommit[^\d]+0/) ? 1 : 0;
# TODO - Fix mod_perl 2.0 here
-if(!$Rollback{$Idx} and $needCleanup and
Apache-can('push_handlers')) {
+if(!$Rollback{$Idx} and $needCleanup) {
print STDERR $prefix push PerlCleanupHandler \n if
$Apache::DBI::DEBUG 1;
-Apache-push_handlers(PerlCleanupHandler, \cleanup);
+Apache-server-push_handlers(PerlCleanupHandler, \cleanup);
# make sure, that the rollback is called only once for every
# request, even if the script calls connect more than once
$Rollback{$Idx} = 1;
--
Haroon Rafique
[EMAIL PROTECTED]
Re: Apache::DBI on mp2
FWIW, we are discussing the internal DBI pooling mechanism at the dbi-dev list
and having already a sort-of-working prototype. So hopefully there will be no
need for Apache::DBI in the near future, as DBI will be able to handle pooling
internally. However it may take some time, as the drivers will have to adjust
to support the new functionality.
You can see the thread here:
http://archive.develooper.com/[EMAIL PROTECTED]/index.html#02118
Some working examples are attached to this message:
http://archive.develooper.com/[EMAIL PROTECTED]/msg02134.html
Haroon Rafique wrote:
My setup is as follows:
Apache/2.0.44 (Gentoo/Linux) mod_perl/1.99_08 Perl/v5.8.0
mod_perl was built from CVS.
I was interested in getting Apache::DBI to run under mp2. I did read
Ask's message at
http://marc.theaimsgroup.com/?l=apache-modperlm=104225578207460w=2
which leads me to my question. What would it take to get connect_on_init
to run under mp2?
With the following patch I was able to get connect_on_init to work under
mp2. Remember that my objective was to JUST get it to run. This is NOT
release quality code. I'm happy to report that it works for me, so far.
Anyone else who is running mp2 (no compat mode) willing to give it a try?
Of course, then the gurus can come in and clean up the code so that it
works under either mp1 or mp2.
If you apply the following patch (will commit it soon) against the modperl-2.0
source, you will be able to use connect_on_init unmodified, assuming that
Apache::compat was loaded before Apache::DBI. Let me know whether it works for
you.
Index: lib/Apache/compat.pm
===
RCS file: /home/cvs/modperl-2.0/lib/Apache/compat.pm,v
retrieving revision 1.81
diff -u -r1.81 compat.pm
--- lib/Apache/compat.pm19 Feb 2003 23:55:23 - 1.81
+++ lib/Apache/compat.pm3 Mar 2003 23:49:19 -
@@ -125,6 +125,16 @@
die $err if $err;
}
+sub push_handlers {
+shift;
+Apache-server-push_handlers(@_);
+}
+
+sub set_handlers {
+shift;
+Apache-server-set_handlers(@_);
+}
+
package Apache::Constants;
use Apache::Const ();
__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Apache dies when configure mod_perl for use with Apache::DBI
Richard Clarke wrote: PerlModule Apache::DBI;-- trouble line This line belongs in your httpd.conf file. PerlModule is an apache configuration directive, not a perl 'command'. http://perl.apache.org/docs/1.0/guide/config.html#PerlModule_and_PerlRequire _Directives Ric. Sorry about the typo, but I've tried it with the 'use' also. The 'startup.pl' that is in the link above to which you refer gives the same result too. Feite -- _BR PRE Osiris-IT Bovenweg 34 8422 DH Nijeberkoop Tel.: 0516-441540 e-mail : [EMAIL PROTECTED] website : A HREF=http://www.osiris-it.nl;http://www.osiris-it.nl/A /PRE
Re: Apache dies when configure mod_perl for use with Apache::DBI
Feite Brekeveld wrote: Richard Clarke wrote: PerlModule Apache::DBI;-- trouble line This line belongs in your httpd.conf file. PerlModule is an apache configuration directive, not a perl 'command'. http://perl.apache.org/docs/1.0/guide/config.html#PerlModule_and_PerlRequire _Directives Ric. Sorry about the typo, but I've tried it with the 'use' also. The 'startup.pl' that is in the link above to which you refer gives the same result too. make sure that you are using the latest DBI and Apache::DBI __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Apache dies when configure mod_perl for use with Apache::DBI
As soon as I activate the line identified as 'trouble line', my apache server dies. Can you elaborate on this.. how does it die?, what is the error msg? etc.. (That is assuming it's still a problem after upgrading to latest DBI/Apache::DBI as Stas suggested). Ric.
Re: Apache dies when configure mod_perl for use with Apache::DBI
Richard Clarke wrote: As soon as I activate the line identified as 'trouble line', my apache server dies. Can you elaborate on this.. how does it die?, what is the error msg? etc.. (That is assuming it's still a problem after upgrading to latest DBI/Apache::DBI as Stas suggested). Ric. This is the only error line that appears in the error_log. [Sun Mar 2 20:10:19 2003] [notice] caught SIGTERM, shutting down As Stas suggested I downloaded the latest versions of DBI and Apache::DBI, and still got the error. But this time it was Apache::Status which was before Apache::DBI in the startup file. At the moment of posting I hadn't included Apache::Status so probably the minor version differences were the problem. Thanks for the support. Feite
RE: Apache dies when configure mod_perl for use with Apache::DBI
This is the only error line that appears in the error_log. [Sun Mar 2 20:10:19 2003] [notice] caught SIGTERM, shutting down Perhaps it's me, but could you please create a copy-n-paste mail with the (correct) relevant code snippets (httpd.conf, startup.pl, etc.). This might help. Best regards, Frank
Apache dies when configure mod_perl for use with Apache::DBI
Hi,
I'm trying to configure mod_perl for use with persistent database
connections with Apache::DBI
RedHat 7.3
Apache 1.3.23
mod_perl 1.26
I've configured the following 'startup.pl' file:
-
#!/usr/bin/perl
BEGIN {
use Apache ();
use lib '/etc/httpd/lib/perl';
}
use Apache::Registry ();
use Apache::Constants();
use CGI qw(-compile :all);
use CGI::Carp ();
#
PerlModule Apache::DBI;-- trouble line
#use LWP ();
#
1;
---
As soon as I activate the line identified as 'trouble line', my apache
server dies.
Any suggestions ?
Thanks,
Feite Brekeveld
Re: Apache dies when configure mod_perl for use with Apache::DBI
PerlModule Apache::DBI;-- trouble line This line belongs in your httpd.conf file. PerlModule is an apache configuration directive, not a perl 'command'. http://perl.apache.org/docs/1.0/guide/config.html#PerlModule_and_PerlRequire _Directives Ric.
Re: Apache::DBI and mod_perl 2
[EMAIL PROTECTED] wrote: Any plans to make Apache::FakeRequest work well enough to make this possible? [EMAIL PROTECTED] wrote: As for mod_perl 1.0, I'm not sure, but if you can make it useful that would be cool. A while back Andrew Ho posted his script, apr, that is similar to Apache::FakeRequest: http://marc.theaimsgroup.com/?l=apache-modperlm=98719810927157w=2 I've attached a slightly updated version called runtsp. Although it's called runtsp, it should handle Apache::Registry scripts just fine. (Tellme::Apache::TSP is our templating module a la Apache::ASP.) - Kyle runtsp Description: Binary data
RE: Apache::DBI and mod_perl 2
Also remember, that you can't test modules that require mod_perl to run from the command line. You'd have the same result with mod_perl 1.0 Thanks, I didn't know that at all as I test all my modules that way and have never had a problem.. Of course most are not mod_perl specific. -Chris
Re: Apache::DBI and mod_perl 2
[EMAIL PROTECTED] wrote: Any plans to make Apache::FakeRequest work well enough to make this possible? There are plans. Here is an entry from modperl-2.0/todo/api.txt: Apache::FakeRequest: since APR can be used outside of httpd, and we can alloc request_rec and similar structures, it should be possible to bootstrap an inside-httpd interface and outside-httpd interface. its not really worthwhile looking at until APR actually installs its *.so or *.a libraries somewhere apxs can find them. and, there's a bunch of util functions (e.g. URI stuff) that is supposed to move from httpd into apr-util. As for mod_perl 1.0, I'm not sure, but if you can make it useful that would be cool. __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Apache::DBI and mod_perl 2
Chris Faust wrote: Hey Helmut, Yes, I'm sure its Apache::DBI - when I try to check for it directly via perl -MModule::Name, I get the error.. Where is a copy paste from the command line. [chrisf@web1 chrisf]$ perl -MApache::DBI -e 0 Can't locate Apache/Constants.pm in @INC (@INC contains: /usr/lib/perl5/5.8.0/i386-linux-thread-multi /usr/lib/perl5/5.8.0 [...] Also remember, that you can't test modules that require mod_perl to run from the command line. You'd have the same result with mod_perl 1.0 __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Apache::DBI and mod_perl 2
Hi, My problem seems like one that would be well documented, but I can't find anything in any of the docs and even goggle groups only had one message and the solution didn't relate. Anyway, I've updated to RedHat 8.0 and Apache 2.0.44 with Mod_Perl 1.99.08 and if I try to use Apache::DBI I receive the error of: Can't locate Apache/Constants.pm in @INC I've learned in mod_perl 2 that Apache::Constants was replaced by 3 new classes (Apache::Const,APR::Const,Modperl::Const). But what do I do to get Apache::DBI to work? Am I missing something really simple here (I hope)? Thanks -Chris
Re: Apache::DBI and mod_perl 2
Hi Chris, are you shure that is is the Apache::DBI, that needs the Apache::Constants or is it another module? For me Apache::DBI loads without problems (2.044/1.9908/5.8) even without the use compat(); compatibility layer. Helmut --On Friday, February 14, 2003 09:00:31 -0500 Chris Faust [EMAIL PROTECTED] wrote: Hi, My problem seems like one that would be well documented, but I can't find anything in any of the docs and even goggle groups only had one message and the solution didn't relate. Anyway, I've updated to RedHat 8.0 and Apache 2.0.44 with Mod_Perl 1.99.08 and if I try to use Apache::DBI I receive the error of: Can't locate Apache/Constants.pm in @INC I've learned in mod_perl 2 that Apache::Constants was replaced by 3 new classes (Apache::Const,APR::Const,Modperl::Const). But what do I do to get Apache::DBI to work? Am I missing something really simple here (I hope)? Thanks -Chris
Re: Apache::DBI and mod_perl 2
Do you have the latest Apache::DBI ? Ask made a new one a couple of weeks
ago to run with mp2.
On Fri, 14 Feb 2003, Chris Faust wrote:
Hi,
My problem seems like one that would be well documented, but I can't find
anything in any of the docs and even goggle groups only had one message and
the solution didn't relate.
Anyway, I've updated to RedHat 8.0 and Apache 2.0.44 with Mod_Perl 1.99.08
and if I try to use Apache::DBI I receive the error of:
Can't locate Apache/Constants.pm in @INC
I've learned in mod_perl 2 that Apache::Constants was replaced by 3 new
classes (Apache::Const,APR::Const,Modperl::Const).
But what do I do to get Apache::DBI to work?
Am I missing something really simple here (I hope)?
Thanks
-Chris
- nick
Nick Tonkin {|8^)
RE: Apache::DBI and mod_perl 2
Hey Helmut, Yes, I'm sure its Apache::DBI - when I try to check for it directly via perl -MModule::Name, I get the error.. Where is a copy paste from the command line. [chrisf@web1 chrisf]$ perl -MApache::DBI -e 0 Can't locate Apache/Constants.pm in @INC (@INC contains: /usr/lib/perl5/5.8.0/i386-linux-thread-multi /usr/lib/perl5/5.8.0 /usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi /usr/lib/perl5/site_perl/5.8.0 /usr/lib/perl5/site_perl /usr/lib/perl5/vendor_perl/5.8.0/i386-linux-thread-multi /usr/lib/perl5/vendor_perl/5.8.0 /usr/lib/perl5/vendor_perl .) at /usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi/Apache.pm line 6. BEGIN failed--compilation aborted at /usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi/Apache.pm line 6. Compilation failed in require at /usr/lib/perl5/site_perl/5.8.0/Apache/DBI.pm line 3. BEGIN failed--compilation aborted at /usr/lib/perl5/site_perl/5.8.0/Apache/DBI.pm line 3. Compilation failed in require. BEGIN failed--compilation aborted. [chrisf@web1 chrisf]$ I get pretty much the same thing if I try to put it into my statup.pl, scripts or httpd.conf. Thanks -Chris -Original Message- From: Dr. Helmut Zeilinger [mailto:[EMAIL PROTECTED]] Sent: Friday, February 14, 2003 9:26 AM To: Chris Faust; Modperl Subject: Re: Apache::DBI and mod_perl 2 Hi Chris, are you shure that is is the Apache::DBI, that needs the Apache::Constants or is it another module? For me Apache::DBI loads without problems (2.044/1.9908/5.8) even without the use compat(); compatibility layer. Helmut --On Friday, February 14, 2003 09:00:31 -0500 Chris Faust [EMAIL PROTECTED] wrote: Hi, My problem seems like one that would be well documented, but I can't find anything in any of the docs and even goggle groups only had one message and the solution didn't relate. Anyway, I've updated to RedHat 8.0 and Apache 2.0.44 with Mod_Perl 1.99.08 and if I try to use Apache::DBI I receive the error of: Can't locate Apache/Constants.pm in @INC I've learned in mod_perl 2 that Apache::Constants was replaced by 3 new classes (Apache::Const,APR::Const,Modperl::Const). But what do I do to get Apache::DBI to work? Am I missing something really simple here (I hope)? Thanks -Chris
RE: Apache::DBI and mod_perl 2
Maybe that is the problem?
I'm using 0.89 which is the newest from CPAN and that shows Jun 18..
Is there a later version available?
Thanks
-Chris
-Original Message-
From: Nick Tonkin [mailto:[EMAIL PROTECTED]]
Sent: Friday, February 14, 2003 10:22 AM
To: Chris Faust
Cc: Modperl
Subject: Re: Apache::DBI and mod_perl 2
Do you have the latest Apache::DBI ? Ask made a new one a couple of weeks
ago to run with mp2.
On Fri, 14 Feb 2003, Chris Faust wrote:
Hi,
My problem seems like one that would be well documented, but I
can't find
anything in any of the docs and even goggle groups only had
one message and
the solution didn't relate.
Anyway, I've updated to RedHat 8.0 and Apache 2.0.44 with
Mod_Perl 1.99.08
and if I try to use Apache::DBI I receive the error of:
Can't locate Apache/Constants.pm in @INC
I've learned in mod_perl 2 that Apache::Constants was replaced by 3 new
classes (Apache::Const,APR::Const,Modperl::Const).
But what do I do to get Apache::DBI to work?
Am I missing something really simple here (I hope)?
Thanks
-Chris
- nick
Nick Tonkin {|8^)
RE: Apache::DBI and mod_perl 2
On Fri, 14 Feb 2003, Chris Faust wrote:
Maybe that is the problem?
I'm using 0.89 which is the newest from CPAN and that shows Jun 18..
Is there a later version available?
You can always search the archives of this list at
http://marc.theaimsgroup.com/?l=apache-modperlr=1w=2
The message you want is
http://marc.theaimsgroup.com/?l=apache-modperlm=104225578207460w=2
- nick
Nick Tonkin {|8^)
RE: Apache::DBI and mod_perl 2
Awesome!! That must be my problem..
I searched everyplace else, but totally forgot searching the list..
Sorry about that.
Thanks Again!!
-Chris
-Original Message-
From: Nick Tonkin [mailto:[EMAIL PROTECTED]]
Sent: Friday, February 14, 2003 10:46 AM
To: Chris Faust
Cc: Modperl
Subject: RE: Apache::DBI and mod_perl 2
On Fri, 14 Feb 2003, Chris Faust wrote:
Maybe that is the problem?
I'm using 0.89 which is the newest from CPAN and that shows Jun 18..
Is there a later version available?
You can always search the archives of this list at
http://marc.theaimsgroup.com/?l=apache-modperlr=1w=2
The message you want is
http://marc.theaimsgroup.com/?l=apache-modperlm=104225578207460w=2
- nick
Nick Tonkin {|8^)
RE: Connection pool with Apache::DBI and Oracle
I don't understand. The Apache server I am using has 50 ThreadsPerChild (default in httpd.conf). Thus, Apache is able to handle quite a few requests simultaneously. However, Oracle has only one session for the job. As a consequence, starting two identical requests from distinct clients leads to blocking the second request until the first one is served. Now, to my modest understanding, this is bottleneck. But maybe I'm doing something wrong here. Or perhaps I have misunderstood something. -Original Message- From: Perrin Harkins [SMTP:[EMAIL PROTECTED]] Sent: Friday, January 24, 2003 7:30 PM To: Georg Botorog Cc: [EMAIL PROTECTED] Subject: Re: Connection pool with Apache::DBI and Oracle Georg Botorog wrote: More precisely, I am using Apache::DBI to create and cache the connection to the DB. As this connection uses a single Oracle session, it is obvious that it becomes a bottleneck. Apache::DBI uses one connection per process. There is no bottleneck there. Each process only handles one request at a time so it would have no use for more than one database connection. Ideally, one would have a pool of DB sessions (= DB handles) that the Apache threads would use in serving the requests coming from clients. That's only ideal if your code spends a lot of time doing things that don't involve a database. You shgould be running with a reverse proxy in front, so that mod_perl processed will not be serving static files. Alternatively, is it possible to convince several Apache servers running concurrently to cooperate (i.e., load balance) in answering incoming requests? If yes, how? Any load-balancer will do that. There are dozens, both commercial and open source. See the mod_perl documentation for a list you can start with. - Perrin
Re: [mp2] Connection pool with Apache::DBI and Oracle
Georg Botorog wrote: I don't understand. The Apache server I am using has 50 ThreadsPerChild If you want help with mod_perl 2, you need to say so. Otherwise it is assumed you are using 1.x. Put [mp2] in your subject line. Thus, Apache is able to handle quite a few requests simultaneously. However, Oracle has only one session for the job. Each thread has its own Perl interpreter and each one of those will have a persistent DBI connection when using Apache::DBI. Nothing is shared between threads unless you explicitly make it shared. There is currently no way to share DBI handles between threads. If you're interested in working on that problem, you can read the archived posts on the topic. As I mentioned in the last message, sharing doesn't help much unless you have a lot of mod_perl code that doesn't use database connections. As a consequence, starting two identical requests from distinct clients leads to blocking the second request until the first one is served. Absolutely not. There is no sharing and thus no blocking. - Perrin
Re: [mp2] Connection pool with Apache::DBI and Oracle
Georg Botorog wrote: Actuallly, I had no idea I am using mp2. I have downloaded some time ago a bundle with Perl, Apache, etc. (for NT), and I'm still using it today. Ah, okay NT is another key piece of information. Sorry, I don't use apache on NT so I thought that was a mp2 directive. So, you are using 1.x on NT. With 1.x, all requests are handled serially on NT, which explains the behavior you're getting. It's actually not related to DBI at all. See http://perl.apache.org/docs/1.0/os/win32/multithread.html for the full story. - Perrin
Connection pool with Apache::DBI and Oracle
Hi, I would like to know if there is a module that implements a pool of connections to an Oracle database. More precisely, I am using Apache::DBI to create and cache the connection to the DB. As this connection uses a single Oracle session, it is obvious that it becomes a bottleneck. On the other hand, opening and closing a connection for each request (i.e., using DBI instead of Apache::DBI) is not acceptable. Ideally, one would have a pool of DB sessions (= DB handles) that the Apache threads would use in serving the requests coming from clients. Was such functionality implemented? Alternatively, is it possible to convince several Apache servers running concurrently to cooperate (i.e., load balance) in answering incoming requests? If yes, how? Thanks, George
Re: Connection pool with Apache::DBI and Oracle
Georg Botorog wrote: More precisely, I am using Apache::DBI to create and cache the connection to the DB. As this connection uses a single Oracle session, it is obvious that it becomes a bottleneck. Apache::DBI uses one connection per process. There is no bottleneck there. Each process only handles one request at a time so it would have no use for more than one database connection. Ideally, one would have a pool of DB sessions (= DB handles) that the Apache threads would use in serving the requests coming from clients. That's only ideal if your code spends a lot of time doing things that don't involve a database. You shgould be running with a reverse proxy in front, so that mod_perl processed will not be serving static files. Alternatively, is it possible to convince several Apache servers running concurrently to cooperate (i.e., load balance) in answering incoming requests? If yes, how? Any load-balancer will do that. There are dozens, both commercial and open source. See the mod_perl documentation for a list you can start with. - Perrin
RE: [ANNOUNCE] Apache::DBI 0.90_02
WOW! I had heard moving A:DBI to 2 was going to be very difficult! I've been waiting... I'll try it this weekend... Thanks and Aloha = Beau; -Original Message- From: Ask Bjoern Hansen [mailto:[EMAIL PROTECTED]] Sent: Friday, January 10, 2003 5:30 PM To: [EMAIL PROTECTED] Subject: [ANNOUNCE] Apache::DBI 0.90_02 Last night I spent a bit of time making a proper test for Apache::DBI and make it work without Apache.pm. Just now I made it work with mod_perl 2.0. I have only tested that very briefly. Until it hits your CPAN mirror, get it from: http://develooper.com/code/Apache::DBI/ Or from CVS; instructions at http://dev.perl.org/cvs/info?module=Apache/DBI/ Please try it out if you have a chance. I would also like to see more tests added to the t/ directory. - ask Apache-DBI-0.90_02.tar.gz has entered CPAN as file: $CPAN/authors/id/A/AB/ABH/Apache-DBI-0.90_02.tar.gz size: 26770 bytes md5: e8c1082b19ad6a01bd572e13628da17d Changes since 0.89: 0.90_02 January 10, 2003 - Changes to make Apache::DBI load and function under mod_perl 2.0. A few important notes: connect_on_init does not work yet and there's no automatic RollBack cleanup handler when autocommit is turned off. 0.90_01 January 10, 2003 - Only call Apache::Status if Apache.pm is completely loaded - Make Test::More a prerequisite so we can do real tests - Make DBI.pm a prerequisite - Add a simple, but real, test script. Requires DBD::mysql and a test database
Re: [ANNOUNCE] Apache::DBI 0.90_02
Beau E. Cox wrote: WOW! I had heard moving A:DBI to 2 was going to be very difficult! I've been waiting... I think it's not what you think. The difficult thing is the pool over threads support, so you can re-use the same connection over all threads in the process. 0.90_02 version has a pool per proc/thread, no sharing. But you still benefit from the per-process cache just as in mod_perl 1.0. [...] 0.90_02 January 10, 2003 - Changes to make Apache::DBI load and function under mod_perl 2.0. __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
RE: [ANNOUNCE] Apache::DBI 0.90_02
On Fri, 10 Jan 2003, Beau E. Cox wrote: I had heard moving A:DBI to 2 was going to be very difficult! I've been waiting... As Stas said, it really wasn't. You might even have been able to with Apache::compat; I did not try. The harder part is to make the database handles shared across a pool of threads. But just having it work like it does in Apache 1.x is much better than not having it work at all! :-) - ask -- ask bjoern hansen, http://www.askbjoernhansen.com/ !try; do();
[ANNOUNCE] Apache::DBI 0.90_02
Last night I spent a bit of time making a proper test for Apache::DBI and make it work without Apache.pm. Just now I made it work with mod_perl 2.0. I have only tested that very briefly. Until it hits your CPAN mirror, get it from: http://develooper.com/code/Apache::DBI/ Or from CVS; instructions at http://dev.perl.org/cvs/info?module=Apache/DBI/ Please try it out if you have a chance. I would also like to see more tests added to the t/ directory. - ask Apache-DBI-0.90_02.tar.gz has entered CPAN as file: $CPAN/authors/id/A/AB/ABH/Apache-DBI-0.90_02.tar.gz size: 26770 bytes md5: e8c1082b19ad6a01bd572e13628da17d Changes since 0.89: 0.90_02 January 10, 2003 - Changes to make Apache::DBI load and function under mod_perl 2.0. A few important notes: connect_on_init does not work yet and there's no automatic RollBack cleanup handler when autocommit is turned off. 0.90_01 January 10, 2003 - Only call Apache::Status if Apache.pm is completely loaded - Make Test::More a prerequisite so we can do real tests - Make DBI.pm a prerequisite - Add a simple, but real, test script. Requires DBD::mysql and a test database
Re: Apache::DBI
On Mon, 6 Jan 2003, Paul Simon wrote: --- Randy Kobes [EMAIL PROTECTED] wrote: Are you using the latest versions of DBI and DBD::ODBC? If not, does an upgrade help? Those modules are - whatever was bundled with your first, warmly supplied :), Perl 5.8 + apache2 package on theoryx5. Possibly, DBI = 1.30 and DBD::ODBC = 0.43 If this is still a problem, you might try an upgrade - both DBI and DBD::ODBC are at newer versions now. We have ppm packages (for ActivePerl 8xx builds) of them at http://theoryx5.uwinnipeg.ca/ppms/ -- best regards, randy
Re: Apache::DBI
Paul Simon wrote: I wasn't sure if Apache::DBI was screwing with ORACLE, especially with persistent connections... The Apache::DBI code is really short and easy to read. Basically, it just doesn't close connections when you call disconnect. It also does automatic rollbacks at the end of each request to make sure nothing is left in a bad state, and it pings the db connection each time you ask for one to make sure it's still alive. There's nothing in there that should interfere with the normal workings of DBI. - Perrin
Apache::DBI
Hi all
I have a feeling this may be [OT], take it to the DBI
list... But I'm hoping to eliminate as much as
possible any suspicion that Apache::DBI/mod_perl is
causing my headache. I'm trying to push this platform
at work ;) If anyone can shed some light on this then
I'd be very appreciative, of course.
I have what's becoming a reoccuring problem with an
app running under:
Apache/2.0.42 (Win32) mod_perl/1.99_08-dev Perl/v5.8.0
I'm using Apache::compat and Apache::DBI for
persistent database connections.
Here are the configurations in the httpd.conf file:
#
LoadFile C:/Perl/bin/perl58.dll
LoadModule perl_module modules/mod_perl.so
PerlOptions +Parent
PerlInterpStart 10
PerlInterpMax 50
PerlInterpMaxSpare 25
PerlRequire C:/Apache2pl/conf/startup.pl
#-
The startup.pl looks like this:
#-
#!C:/Perl/bin/Perl.exe
use Apache2();
use lib('/Apache2pl/lib/perl/Apache');
use ModPerl::Registry();
use Apache::compat;
use Apache::DBI;
use DBI;
use DBD::ODBC;
use HTML::Template;
use CGI::Lite;
#$Apache::DBI::DEBUG = 2;
use Standard3;
1;
#-
For completeness sake, here's the connection string:
my $DBH = DBI-connect(DBI:ODBC:$db, $user, $pass,
{ RaiseError = 1, PrintError = 1, AutoCommit = 1 })
or print( Unable to connect to Database:
$DBI::errstr\n ) ;
Finally, the error message I'm getting is:
DBI-connect(pdb9) failed:
[Oracle][ODBC][Ora]ORA-12535: TNS:operation timed out
(SQL-S1000)(DBD: db_login/SQLConnect err=-1) at
/Apache2/lib/perl/Apache/Standard3.pm line 29
This problem goes away if the ORacle server(on it's
own hardware running windows 2000 pro) is restarted.
The last time this happened the box Oracle resides on
needed a cold reboot! So far, I haven't had to restart
apache.
Could Apache::DBI or mod_perl2 cause this behavior?
Paul
RE: Apache::DBI
Hi Paul -
It is my understanding that Apache::DBI is not yet
implemented for Apache2/mod_perl2. I had to comment
out my references to it in the startup script and/or
the configuration file.
Take a look at:
http://beaucox.com/mason/mason-with-apmp2-mini-HOWTO.htm
for further info.
Aloha = Beau.
-Original Message-
From: Paul Simon [mailto:[EMAIL PROTECTED]]
Sent: Thursday, January 02, 2003 3:00 AM
To: [EMAIL PROTECTED]
Subject: Apache::DBI
Hi all
I have a feeling this may be [OT], take it to the DBI
list... But I'm hoping to eliminate as much as
possible any suspicion that Apache::DBI/mod_perl is
causing my headache. I'm trying to push this platform
at work ;) If anyone can shed some light on this then
I'd be very appreciative, of course.
I have what's becoming a reoccuring problem with an
app running under:
Apache/2.0.42 (Win32) mod_perl/1.99_08-dev Perl/v5.8.0
I'm using Apache::compat and Apache::DBI for
persistent database connections.
Here are the configurations in the httpd.conf file:
#
LoadFile C:/Perl/bin/perl58.dll
LoadModule perl_module modules/mod_perl.so
PerlOptions +Parent
PerlInterpStart 10
PerlInterpMax 50
PerlInterpMaxSpare 25
PerlRequire C:/Apache2pl/conf/startup.pl
#-
The startup.pl looks like this:
#-
#!C:/Perl/bin/Perl.exe
use Apache2();
use lib('/Apache2pl/lib/perl/Apache');
use ModPerl::Registry();
use Apache::compat;
use Apache::DBI;
use DBI;
use DBD::ODBC;
use HTML::Template;
use CGI::Lite;
#$Apache::DBI::DEBUG = 2;
use Standard3;
1;
#-
For completeness sake, here's the connection string:
my $DBH = DBI-connect(DBI:ODBC:$db, $user, $pass,
{ RaiseError = 1, PrintError = 1, AutoCommit = 1 })
or print( Unable to connect to Database:
$DBI::errstr\n ) ;
Finally, the error message I'm getting is:
DBI-connect(pdb9) failed:
[Oracle][ODBC][Ora]ORA-12535: TNS:operation timed out
(SQL-S1000)(DBD: db_login/SQLConnect err=-1) at
/Apache2/lib/perl/Apache/Standard3.pm line 29
This problem goes away if the ORacle server(on it's
own hardware running windows 2000 pro) is restarted.
The last time this happened the box Oracle resides on
needed a cold reboot! So far, I haven't had to restart
apache.
Could Apache::DBI or mod_perl2 cause this behavior?
Paul
Re: Apache::DBI
On Thu, 2 Jan 2003, Paul Simon wrote:
Hi all
I have a feeling this may be [OT], take it to the DBI
list... But I'm hoping to eliminate as much as
possible any suspicion that Apache::DBI/mod_perl is
causing my headache. I'm trying to push this platform
at work ;) If anyone can shed some light on this then
I'd be very appreciative, of course.
I have what's becoming a reoccuring problem with an
app running under:
Apache/2.0.42 (Win32) mod_perl/1.99_08-dev Perl/v5.8.0
I'm using Apache::compat and Apache::DBI for
persistent database connections.
[ ... ]
For completeness sake, here's the connection string:
my $DBH = DBI-connect(DBI:ODBC:$db, $user, $pass,
{ RaiseError = 1, PrintError = 1, AutoCommit = 1 })
or print( Unable to connect to Database:
$DBI::errstr\n ) ;
Finally, the error message I'm getting is:
DBI-connect(pdb9) failed:
[Oracle][ODBC][Ora]ORA-12535: TNS:operation timed out
(SQL-S1000)(DBD: db_login/SQLConnect err=-1) at
/Apache2/lib/perl/Apache/Standard3.pm line 29
This problem goes away if the ORacle server(on it's
own hardware running windows 2000 pro) is restarted.
The last time this happened the box Oracle resides on
needed a cold reboot! So far, I haven't had to restart
apache.
Could Apache::DBI or mod_perl2 cause this behavior?
When you say the problem goes away, does this mean that
things work fine after the restart of the Oracle server?
Or do you periodically have to do this restart?
Are you using the latest versions of DBI and DBD::ODBC?
If not, does an upgrade help?
--
best regards,
randy kobes
Apache::DBI and db proxies
Folks, is there any benefit in using Apache::DBI when all db calls ought to go through db proxies? Thanks in advance -r
Re: Apache::DBI seg fault
On Wed, 20 Nov 2002, Beau E. Cox wrote: I am using Apache::DBI on my test server - all OK. When I try to use it on my production server, I get the following- stdout: Shutting down httpd..done Starting httpd [ PERL ] Syntax OK stderr: /etc/init.d/apache: line 206: 18040 Segmentation fault $HTTPD_BIN $INET6 -t -f /etc/httpd/httpd.conf $MODULES /var/log/httpd/rcapache.log 21 ..failed [ .. ] BOTH the test and production servers are using: Apache/1.3.26 (Linux/SuSE) mod_perl/1.27 Linux/SuSE 8.1 - both with the latest patches. I can find nothing in the httpd logs. I know it must be some difference in my environment between the test and production servers, but I am at wits end on how to track this problem down. Could someone please push me in the right direction? Aloha = Beau. Are both servers running the latest versions of DBI and the relevant DBD::* driver? If not, try upgrading to see if that helps. -- best regards, randy kobes
RE: Apache::DBI seg fault
Randy - Thank you, I owe you lunch. I thought I checked all relevant module versions, but your msg spurred me to check again: DBI 1.28 was on production while DBI 1.30 was on test! 1.30 WORKS! 1.28 DOESN'T WORK. All is well - I am one happy camper ;) Aloha = Beau. -Original Message- From: Randy Kobes [mailto:[EMAIL PROTECTED]] Sent: Thursday, November 21, 2002 4:57 AM To: Beau E. Cox Cc: Modperl Subject: Re: Apache::DBI seg fault On Wed, 20 Nov 2002, Beau E. Cox wrote: I am using Apache::DBI on my test server - all OK. When I try to use it on my production server, I get the following- stdout: Shutting down httpd..done Starting httpd [ PERL ] Syntax OK stderr: /etc/init.d/apache: line 206: 18040 Segmentation fault $HTTPD_BIN $INET6 -t -f /etc/httpd/httpd.conf $MODULES /var/log/httpd/rcapache.log 21 ..failed [ .. ] BOTH the test and production servers are using: Apache/1.3.26 (Linux/SuSE) mod_perl/1.27 Linux/SuSE 8.1 - both with the latest patches. I can find nothing in the httpd logs. I know it must be some difference in my environment between the test and production servers, but I am at wits end on how to track this problem down. Could someone please push me in the right direction? Aloha = Beau. Are both servers running the latest versions of DBI and the relevant DBD::* driver? If not, try upgrading to see if that helps. -- best regards, randy kobes
Apache::DBI seg fault
Hi - I am using Apache::DBI on my test server - all OK. When I try to use it on my production server, I get the following- stdout: Shutting down httpd..done Starting httpd [ PERL ] Syntax OK stderr: /etc/init.d/apache: line 206: 18040 Segmentation fault $HTTPD_BIN $INET6 -t -f /etc/httpd/httpd.conf $MODULES /var/log/httpd/rcapache.log 21 ..failed The rcapache.log file has _only_: Syntax OK My httpd.conf has: IfModule mod_perl.c PerlModule Apache::DBI before any other includes; I have commented out my startup script so that I am not actually using any Apache::DBI methods. BOTH the test and production servers are using: Apache/1.3.26 (Linux/SuSE) mod_perl/1.27 Linux/SuSE 8.1 - both with the latest patches. I can find nothing in the httpd logs. I know it must be some difference in my environment between the test and production servers, but I am at wits end on how to track this problem down. Could someone please push me in the right direction? Aloha = Beau.
Re: Apache::DBI and password security
On Fri, 15 Nov 2002, [iso-8859-1] Faßhauer, Wolfgang, FCI3 wrote: one database user because of resource limits. The problem I see is that the password for connecting to the database is clear readable in the perl script. Does anybody know how to hide that password? Have you thought of running your webserver as some 'www' user? You can then make your scripts readonly by a 'dev' group which the www user and the developes are members of.
Re: Apache::DBI and password security
On Fri, 15 Nov 2002, Rafiq Ismail (ADMIN) wrote: On Fri, 15 Nov 2002, [iso-8859-1] Faßhauer, Wolfgang, FCI3 wrote: one database user because of resource limits. The problem I see is that the password for connecting to the database is clear readable in the perl script. Does anybody know how to hide that password? Have you thought of running your webserver as some 'www' user? You can then make your scripts readonly by a 'dev' group which the www user and the developes are members of. CORRECT: 'readonly' should be 'only readable' by R.
AW: Apache::DBI and password security
Hi, I want to build a database application based on mod_perl and Apache::DBI. The goal of Apache::DBI is to get persistent database connections using only one database user because of resource limits. The problem I see is that the password for connecting to the database is clear readable in the perl script. Does anybody know how to hide that password? I think, storing it in a file for reading by the script is not the right way (?). Thanks for help! - Wolfgang Have you thought of running your webserver as some 'www' user? You can then make your scripts readonly by a 'dev' group which the www user and the developes are members of. CORRECT: 'readonly' should be 'only readable' by Yes, that's our plan, too. But the risk still remains that someone will get a look to the script. I think, there is a golden rule: Never put clear text passwords in files. Those files are stored in archives by backup for example. There maybe a lot of people (sysadmin, developer, ...) concerned with the webserver. So it's not easy to secure it. - Wolfgang
Re: AW: Apache::DBI and password security
On Fri, 15 Nov 2002, [iso-8859-1] Faßhauer, Wolfgang, FCI3 wrote: Have you thought of running your webserver as some 'www' user? You can then make your scripts readonly by a 'dev' group which the www user and the developes are members of. CORRECT: 'readonly' should be 'only readable' by Yes, that's our plan, too. But the risk still remains that someone will get a look to the script. I think, there is a golden rule: Never put clear text passwords in files. Those files are stored in archives by backup for example. There maybe a lot of people (sysadmin, developer, ...) concerned with the webserver. So it's not easy to secure it. A thought, although I've never been so secure myself and I'm not sure how secure this would be - but it's one of those silly convoluted ideas you have to tell someone. Since you're using mod_perl and apache_dbi, this is just a thought. Use the Crypt::Blowfish_PP to generate an encrypted password and place it as a variable in a package somewhere. During server startup take a password from the command line, some sort of: Perl Paranoid::CryptDBIPassword::promptForPassword /Perl getliner. Take the value as my $key and: my $bfish = Crypt::Blowfish_PP-new($key) $Apache::PARANOID::dbiPassword = $bfish-decrypt($encryptedPassword); then whenever you want your password you access $Apache::PARANOID::dbiPassword. Hmm. I think that the guy who wrote Blowfish_PP would cut my danglies off for that one. R.
AW: Apache::DBI and password security
Yes, that's our plan, too. But the risk still remains that someone will get a look to the script. I think, there is a golden rule: Never put clear text passwords in files. Those files are stored in archives by backup for example. There maybe a lot of people (sysadmin, developer, ...) concerned with the webserver. So it's not easy to secure it. A thought, although I've never been so secure myself and I'm not sure how secure this would be - but it's one of those silly convoluted ideas you have to tell someone. Since you're using mod_perl and apache_dbi, this is just a thought. Use the Crypt::Blowfish_PP to generate an encrypted password and place it as a variable in a package somewhere. During server startup take a password from the command line, some sort of: Perl Paranoid::CryptDBIPassword::promptForPassword /Perl getliner. Take the value as my $key and: =09my $bfish =3D Crypt::Blowfish_PP-new($key) =09$Apache::PARANOID::dbiPassword =09=3D $bfish-decrypt($encryptedPassword); then whenever you want your password you access $Apache::PARANOID::dbiPassword. Hmm. I think that the guy who wrote Blowfish_PP would cut my danglies off for that one. R. This is an interesting idea. Many thanks to you, Rafiq! - Wolfgang
Re: AW: Apache::DBI and password security
On Fri, 15 Nov 2002, [iso-8859-1] Faßhauer, Wolfgang, FCI3 wrote: Hmm. I think that the guy who wrote Blowfish_PP would cut my danglies off for that one. This is an interesting idea. Cutting my danglies off? hmm. Sounds painful. Many thanks to you, Rafiq! s'ok, although I wouldn't implement this myself. There are probably nicer ways of being paranoid out there. And just use Crypt::Blowfish if you really want to use Blowfish. :) Good luck. R.
Re: AW: Apache::DBI and password security
On Fri, Nov 15, 2002 at 12:52:13PM +, Rafiq Ismail (ADMIN) wrote: $Apache::PARANOID::dbiPassword = $bfish-decrypt($encryptedPassword); then whenever you want your password you access $Apache::PARANOID::dbiPassword. Hmm. I think that the guy who wrote Blowfish_PP would cut my danglies off for that one. Which is why you copied him in the first place? :-) In general, though, there isn't a good way to get any security from any system that has to be able to access sensitive data in an automatic way. MBM -- Matthew Byng-Maddick [EMAIL PROTECTED] http://colondot.net/
Re: AW: Apache::DBI and password security
=?iso-8859-1?Q?=22Fa=DFhauer=2C_Wolfgang=2C_FCI3=22?= [EMAIL PROTECTED] ads.net wrote: Hi, I want to build a database application based on mod_perl and Apache::DBI. The goal of Apache::DBI is to get persistent database connections using only one database user because of resource limits. The problem I see is that the password for connecting to the database is clear readable in the perl script. Does anybody know how to hide that password? I think, storing it in a file for reading by the script is not the right way (?). Thanks for help! - Wolfgang Have you thought of running your webserver as some 'www' user? You can then make your scripts readonly by a 'dev' group which the www user and the developes are members of. CORRECT: 'readonly' should be 'only readable' by Yes, that's our plan, too. But the risk still remains that someone will get a look to the script. I think, there is a golden rule: Never put clear text passwords in files. Those files are stored in archives by backup for example. There maybe a lot of people (sysadmin, developer, ...) concerned with the webserver. So it's not easy to secure it. Something we do is put the password in a file outside the document root. The script reads the file. If running with mod_perl, this can be in a file readable only by root read during server startup (assuming the server starts up as root). Then the password can be cached in memory. If it changes, a graceful restart might be sufficiant, but I haven't tried that yet -- most of our current code is PHP that we're are working on replacing. The last time I played with mod_perl and graceful restarts was the early 1.2x or late 1.1x mod_perl and it didn't always work well, iirc. I think some of that has been fixed. -- James Smith [EMAIL PROTECTED], 979-862-3725 Texas AM CIS Operating Systems Group, Unix
When using Apache::DBI...
Am I correct in this: Apache::DBI can only really do its stuff when you perform a DBI-connect, so by calling $dbh = DBI-connect(..) during PerlChildInit and then never trying to reconnect, you are defeating the purpose of using Apache::DBI. To expand on this, when Apache::DBI intercepts a connection request: * it returns a stored live handle which matches the connection credentials * checks that the handle is indeed still live, and if it isn't, reconnects automatically (potentially destroying any $sth's that you have prepared and retained) So would this be the right balance between efficiency and safety: 1) use Apache::DBI 2) Do my $dbh = DBI-connect() at the beginning of each request (ie as early as required during each request) 3) use my $sth = $dbh-prepare_cached() once as early as required during each request This way, we're not expecting the DBI handle to die during a request, and so avoid calling a few lines of code to -connect and -prepare_cached several times during each request. Have I got the right idea? thanks Clint
Re: When using Apache::DBI...
Clinton Gormley wrote: Am I correct in this: Apache::DBI can only really do its stuff when you perform a DBI-connect, so by calling $dbh = DBI-connect(..) during PerlChildInit and then never trying to reconnect, you are defeating the purpose of using Apache::DBI. That's right. To expand on this, when Apache::DBI intercepts a connection request: * it returns a stored live handle which matches the connection credentials * checks that the handle is indeed still live, and if it isn't, reconnects automatically (potentially destroying any $sth's that you have prepared and retained) It also adds a cleanup handler to issue a rollback of any uncommitted work on that database handle after the request completes. So would this be the right balance between efficiency and safety: 1) use Apache::DBI 2) Do my $dbh = DBI-connect() at the beginning of each request (ie as early as required during each request) 3) use my $sth = $dbh-prepare_cached() once as early as required during each request Yes. The call to prepare_cached won't do anything if that statement is already cached. The way I like to do it is to have a utility class that implements a get_dbh() method. Then I just call that when I want one. Inside of that it can do the DBI-connect business and anything else I need done (maybe resetting the isolation level on that connection if I messed with that anywhere). It can also cache the dbh for the length of the request inside of $r-pnotes if I want to avoid multiple calls to Apache::DBI. - Perrin
POD re-written for Apache::DBI
I just read the POD for Apache::DBI, and then rewrote it.
Hope no-one is offended, that no meaning is lost, and that
the revision is worth looking at and perhaps including on CPAN.
Cheers
lee (now offlist)
=head1 NAME
Apache::DBI - Initiate a persistent database connection
=head1 SYNOPSIS
# Configuration in httpd.conf or startup.pl:
# This must come before all modules which use DBI,
# but after Apache::Status
PerlModule Apache::DBI
# No need to change anything in your scripts
# - the use of this module is absolutely transparent!
=head1 PREREQUISITES
Note that this module needs mod_perl-1.08 or higher, apache_1.3.0 or higher
and that mod_perl needs to be configured with the appropriate call-back hooks:
PERL_CHILD_INIT=1
PERL_STACKED_HANDLERS=1
=head1 DESCRIPTION
This module impliments persistent database connections for mod_perl,
through Perl's DBI. For supported DBI drivers see Lhttp://dbi.perl.org/.
=head1 HOW IT WORKS
When the standard DBI.pm module is loaded after Apache::DBI, and the
environment variable CGATEWAY_INTERFACE starts with CCGI-Perl,
every database Cconnection request is passed to CApache::DBI.
CApache::DBI returns a database handle from a previous Cconnection
request if it is valid (using the Cping method), and if the parameters
defining the connection are exactly the same - including all the Cconnect
attributes.
If no appropriate database handle exists, or if the Cping method fails,
a new connection is established and the handle is stored for later re-use.
As CApache::DBI overloads the Cdisconnect method of CDBI.pm, there
is no need to remove them from your code.
=head1 CAVEATS
=head2 THE PROBLEMS OF PER-PROCESS CONNECTIONS
CApache::DBI still has one limitation: it keeps database connections
persistent on a Iper process basis, with no sharing of database handles
between Apache processes, due to the distinct name-space of every process.
Neither is not possible to create a database handle upon the start-up of
the httpd,
and then to use this to handle every subsequent server, as this would cause
a clash
when the handle is used by two processes at once.
So take care when and where you use this module: there are scenarios where
the use of
CApache::DBI is not encourage. Think about a heavy loaded Web-site where
every
user connects to the database with a unique user ID: every server process
would create
many database handles, each of which would spawn a separate process. In a short
time the web server would be flooded to death.
=head2 TIMEOUTS
Some databases disconnect their clients after a certain period of inactivity.
To detect this, CApache::DBI attempts to validate the database handle using
the LCDBI::ping method|DBI/ping. Because this method returns true by
default,
any driver that does not implement the Cping method will not allow us to
test the validity of our handle.
There are several work-arounds: deactivate use of the ping method (see
L/CONFIGURATION),
replace the Cping call with command you DB driver does support, or
impliment a
Cping method something like this:
{
package DBD::xxx::db; # == YOUR DATABASE ==
use strict;
sub ping {
my($dbh) = @_;
my $ret = 0;
eval {
local $SIG{__DIE__} = sub { return 0 };
local $SIG{__WARN__} = sub { return 0 };
# adapt the select statement to your database:
$ret = $dbh-do('select 1');
};
return $@? 0:$ret;
}
}
=head1 TRANSACTIONS
A standard DBI script will automatically perform a rollback
whenever the script exits. In the case of persistent database connections,
the database handle will not be destroyed and hence no automatic rollback
occurs.
At first glance it does seem possible to handle a transaction over multiple
requests, but this should be avoided, as different requests are handled by
different processes, and one process cannot know the state of a transaction
which initiated by another server.
In general, it is good practice to perform an explicit commit or rollback at
the end of every script. In order to avoid inconsistencies in the database
in case
CAutoCommit is off and the script finishes without an explicit rollback,
CApache::DBI uses a CPerlCleanupHandler to issue a rollback at the
end of every request. Note, that this CCleanupHandler will only be used if
the initial data_source sets CAutoCommit=0. It will Bnot be used if
CAutoCommit
is turned off after the Cconnect request has been performed.
=head1 Apache::Status COMPATABILITY
CApache::DBI includes a menu item plug-in for
LApache::Status|Apache::Status,
which lists extant database connections. This should be considered
incomplete because of
the limitations explained above: it shows the current
Re: Apache::DBI: number of mysql connections vary wildly
Hi there, On Thu, 17 Oct 2002, John Cameron wrote: I am finding that the number of open number of database connections I have open at one time is varying wildly. Then, Suddenly, the number of connctions jumps up to 50 or more! Sometimes this falls back to below 20, but sometimes this keeps climbing. Server load hits over 50 (99.9% taken by mysql) and the system grinds to a halt. Your Apache is spawning new children to serve multiple concurrent requests. It's supposed to do that. The extra children are opening connections to the database. When it has more children than it needs it kills off surplus ones which closes the extra database connections. If your machine can't handle the load you need to reduce the possible load. Check the value of MaxClients in httpd.conf. You can read more about this in the (admittedly intimidating:) documentation, see the mod_perl home page http://perl.apache.org for some links. 73, Ged.
Re: Is there an easy way to trace / debug Apache::DBI (Postgres)leaks?
Hi, thanks for the tips. But I don't seem to be able to locally override
the value of AutoCommit for one handle (I only need to use AutoCommit for
one script!). If I follow the instructions on the URL you pointed me to,
and do something like:
my $dbh = DBI-connect (dbi:Pg:dbname=hello, postgres, foo);
my %orig = ();
my attrs = qw(AutoCommit RaiseError);
$orig{$_} = $dbh-{$_} for attrs;
$dbh-{AutoCommit} = 0; $dbh-{RaiseError} = 1;
When I later do the $dbh-commit, it fails with this in my log file:
commit ineffective with AutoCommit enabled at /usr/lib/perl5/.
So is AutoCommit disallowed for overriding (as this seems to suggest)?
Regards
Kirk Bowe.
On Tue, 15 Oct 2002, Perrin Harkins wrote:
Kirk Bowe wrote:
Unfortunately after a couple of hours of moderate use Postgres reaches its
max_clients level (which is set below max httpds in httpd.conf)
This is usually caused by mistakes in your connection calls where they
have slightly different connect info resulting in multiple connections.
At this point there's no
work being done, so presumably the handles aren't being freed.
Database handles are not supposed to be freed. That's the point of
Apache::DBI. However, you should only have one per httpd process.
Does anyone have any tips on how to, at this point, go about detecting
where the handle leak might be (which I'm presuming is the problem)?
http://perl.apache.org/docs/1.0/guide/databases.html#Debugging_Apache__DBI
should Template::Toolkit be avoided altogether when using mod_perl and
database connectivity?
TT is not related to this. It works great with mod_perl.
- Perrin
Re: Is there an easy way to trace / debug Apache::DBI (Postgres)leaks?
On Wed, 16 Oct 2002, Kirk Bowe wrote:
my $dbh = DBI-connect (dbi:Pg:dbname=hello, postgres, foo);
my %orig = ();
my @attrs = qw(AutoCommit RaiseError);
$orig{$_} = $dbh-{$_} for @attrs;
$dbh-{AutoCommit} = 0; $dbh-{RaiseError} = 1;
When I later do the $dbh-commit, it fails with this in my log file:
I've always done it this way, further the DBI man states:
Enable transactions (by turning AutoCommit off)
until the next call to commit or rollback. After
the next commit or rollback, AutoCommit will
automatically be turned on again.
Although I usually just do a $dbh-{AutoCommit}=1 to re-enable.
Are you sure that there isn't something else changing the AutoCommit back
on, unintentionally?
Rafiq
--
Senior Programmer
Bookings.nl
--
Me::[EMAIL PROTECTED]||www.dreamthought.com
Budget hosting on my 10Mbit/backbone::[EMAIL PROTECTED]
Apache::DBI: number of mysql connections vary wildly
Hi, I am using mod_perl (1.24_01) with Apachi::DBI and Mysql (3.23.37).
I am finding that the number of open number of database connections I have
open at one time is varying wildly.
When I first start Apache and Mysql there are only 8 connections made. Why
8? I have specified that there should be 20 Apache child processes. Should
the db connections match that?
After load on the webserver starts, the number of connections grows, usually
to 20 or below. This is fine, I would expect that.
Then, Suddenly, the number of connctions jumps up to 50 or more! Sometimes
this falls back to below 20, but sometimes this keeps climbing. Server load
hits over 50 (99.9% taken by mysql) and the system grinds to a halt.
Since I am using Apache::DBI, I thought there was meant to be 20 db
connections always, and no more or less.
I am pretty sure that we are always disconnecting our database connections
manually (Though doesn't Apache::DBI override that anyway, and keep one open
per apache process?).
Has anybody had similar issues? Any suggestions? Our apache startup script
is below.
Thanks,
John
/etc/httpd/perl/startup.pl
#!/usr/bin/perl
use strict;
# load up necessary perl function modules to be able to call from Perl-SSI
# files. These objects are reloaded upon server restart (SIGHUP or SIGUSR1)
# if PerlFreshRestart is On in httpd.conf (as of mod_perl 1.03).
# only library-type routines should go in this directory.
use lib /harnesslink/live_html/lib;
# make sure we are in a sane environment.
$ENV{GATEWAY_INTERFACE} =~ /^CGI-Perl/ or die GATEWAY_INTERFACE not Perl!;
use Apache::Registry (); # for things in the /programs URL
use Apache::DBI;
use CGI ();
use Data::Dumper ();
use POSIX ();
use Carp ();
use Image::Magick ();
use HTML::Template ();
use Benchmark::Timer ();
use Date::Manip ();
use Class::Date ();
use MD5 ();
use FreezeThaw ();
use File::Scan ();
# pull in things we will use in most requests so it is read and compiled
# exactly once
use DBD::mysql ();
# Create persistant database connections
Apache::DBI-connect_on_init
(
DBI:mysql:harnesslink,
root,
,
{
AutoCommit = 1,
}
);
$Apache::DBI::DEBUG = 1;
1;
Re: [cgiapp] Re: Apache::DBI and CGI::Application with lots of modules.
Hi, I am learning lots of new things, but still working on the problem itself. It seems to be the case that even when I am running under ./httpd -X I have trouble getting the search query to get stuck. If I do something from the mysql monitor like set an order on hold directly with a query, then the search results won't show the updated status of the order. Yet if from the web interface, I set the order on hold, then reload, the correct status is shown. If I restart apache, then the correct status shows. Thanks for your advice, I am thinking besides the general advice I have received, Apache::DB will be my next most helpfull item. Eric At 02:33 PM 10/14/02 -0400, William McKee wrote: On 14 Oct 2002 at 9:12, Eric Frazier wrote: That I am not so sure of. I will do some more investigation. It seems like the only variables that could be causing this are the result set from the query and the scalar which holds the html template. I feel like I know absolutly nothing now :( I installed Apache::DB but don't yet know what to make of it. Hey Eric, I empathize with you! Getting myself up-to-speed with mod_perl development has been a demanding task. At the moment, my apps have stabilized but I'm sure to hit another hurdle down the road. As for Apache::DB, read the mod_perl guide at perl.apache.org. The debugger is a pain to learn but has helped me to solve several problems. There is good documentation on using the debugger in the camel book as well. One trick I learned was to let the script run through once using the 'c' command. That will load all the scripts and modules into memory which will let you set breaks in your code without having to watch every line go by. Also, I noticed some folks pointing out some global variables. If you're having troubles tracking these down in your script, you can see all the variables your script has instantiated by using perl-status and looking at the Loaded Modules. Find your CGI::App module in the list and click it to get a detailed list of the arrays, functions, hashes, etc. that it loads. Good luck, William -- Lead Developer Knowmad Services Inc. || Internet Applications Database Integration http://www.knowmad.com (250) 655 - 9513 (PST Time Zone) Inquiry is fatal to certainty. -- Will Durant
Re: Apache::DBI and CGI::Application with lots of modules.
Hi, I had to read that over a few times to get it. And now I see that I do indeed have that situation, there are a number of times when I call my $holdstatus = new Holds(); from within a module that also has a new method. What I don't understand is how does my code work at all? Thanks, Eric At 07:13 PM 10/14/02 +0200, Rafiq Ismail wrote: On Mon, 14 Oct 2002, Eric Frazier wrote: That looks like voodoo code copied from a man page. If you call this as Holds-new(), you don't need that junk about ref. (And most people recommend against the new Holds syntax.) I wanted the DBH to be global since just about every sub in Holds does a query of some sort. I guess it doesn't matter either way if I do the connect in the new() vs up top outside of a sub. Boredom break: As for your dbh, stick it whereever its scope applies, however I don't like declaring globals, so I've found that if I make the dbh accessible via an object, usually together with Apache::DBI in the background, I can often do clean up stuff, such as closing the handle (incase Apache::DBI isn't in place with a particular invokation of the package), last system logging updates/inserts, or whatever the job requires in a DESTROY method. What is the problem with the my $holdcheck = new Holds() type of syntax? I never read anything about that either way. It's in the book which I think should be called, 'the guy in the silly hat book,' ie. Damien's OO book, pretty much saying that, The indirect object syntax does, however, suffer from the same type of ambiguity problems that sometime befuddles print my $cd3 = new get_classname() (@data) #Compilation Error ... parapharased type=badly Assuming you have $cd=MyPackage and: get_name $cd; This is usually equivalent to: $cd-get_name; However, let's say that you have a method in the invoking script named 'get_name', then: get_name $cd; Gets interpreted as: get_name(MyPackage) Which is not what you're after. /paraphrase - from the guy in the silly hat book -- Senior Programmer Bookings.nl -- Me::[EMAIL PROTECTED]||www.dreamthought.com Budget hosting on my 10Mbit/backbone::[EMAIL PROTECTED] (250) 655 - 9513 (PST Time Zone) Inquiry is fatal to certainty. -- Will Durant
Re: [cgiapp] Re: Apache::DBI and CGI::Application with lots of modules.
On 15 Oct 2002 at 7:12, Eric Frazier wrote: I am learning lots of new things, but still working on the problem itself. It seems to be the case that even when I am running under ./httpd -X I have trouble getting the search query to get stuck. If I do something from the mysql monitor like set an order on hold directly with a query, then the search results won't show the updated status of the order. Yet if from the web interface, I set the order on hold, then reload, the correct status is shown. If I restart apache, then the correct status shows. That sounds like trouble. The only problem I've had running httpd -X is when I compiled mod_ssl into my server. Apparently, it doesn't like to run in single processor mode (although I haven't confirmed this). Otherwise, the single processor mode should work just like multi-processor. I'd start looking into the code that checks that status. Good luck, William -- Lead Developer Knowmad Services Inc. || Internet Applications Database Integration http://www.knowmad.com
