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
(maybe offtopic) mod_perl/DBI/PostgreSQL
I just noticed an oddity in my application. I setup a table in SQL witha serial, not null, primary key column. Then I have a routine that inserts into the table (not setting the key column). If I do the insert from the psql utitilty the sequence stays consistant (inc by 1) w/each new row added. But when I do it from my mod_perl app, it sometimes jumps by two. I know the sequence will advance even if there's an error, but I'm not getting any error messages back from DBI. Has anyone else run across something like this? I know this is kind of off topic, but it maybe related to mod_perl's consistent state. Oh, I'm using Apache::DBI, not plain DBI. www.bluewolverine.com Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software
Re: (maybe offtopic) mod_perl/DBI/PostgreSQL
Do you have any code that might do a select to determine the value of the sequence used? Example: INSERT blah blah blah; SELECT currval(sequence_name); or somethign like that? If so, the SELECT may be incrementing the counter and that would explain the jump by 2 your seeing. There is a function to determine the value of the sequence without incrementing for postgres, but I don't remember right now what that is. I actually just did something like this myself. Creating an entry in a table and then needing to find out what the entry id was. In my case, I actually ended up just doing a SELECT with a where clause including the data I just inserted, reverse sorted by record creation date (timestamp default now() kind of thing, not included in INSERT statement) with a limit of 1. I know I could have used the function to get the sequence value, but I wasn't absolutely sure what would happen. If two processes incremented the sequence at the same time, what would the function return, the value for that connection's insert, or the value of the other session? Especially when I added Apache::DBI to the mix where db connections appear to be pooled and shared. This way I know I'm getting the value I'm looking for. Greg
Re: (maybe offtopic) mod_perl/DBI/PostgreSQL
Yeah, actually here is the code snippets I use.
Table def:
CREATE SEQUENCE s_league_lid minvalue 1;
CREATE TABLE t_League ( /* lid integer DEFAULT nextval('s_league_lid') PRIMARY KEY,*/ lid SERIAL PRIMARY KEY NOT NULL, name VARCHAR(20) UNIQUE NOT NULL, numdiv integer,
draft integer, last_wvr integer
);
As you can see above, I've tried the manual sequence method and the new convenience method.
in module "new" function:
$self-{sth}-{League_by_lid} = $self-{dbh}-prepare("select * from t_League where lid = ?"); $self-{sth}-{League_by_name} = $self-{dbh}-prepare("select * from t_League where name = ?");
$self-{ith}-{League} = $self-{dbh}-prepare("insert into t_League (name,numdiv,draft,last_wvr) VALUES(?,?,?,?);");
Then in a member function, called later:
call execute on the by_name handle to see if new name already exists
if it doesn't
call execute on the insert handle with the new row data
then call the select by name handle to get the id that was used to create new row.
all of my execute statements have "or die $DBI::errstr;" tacked on the end to catch any errors.
[EMAIL PROTECTED] wrote:
Do you have any code that might do a select to determine the value of thesequence used?Example:INSERT blah blah blah;SELECT currval(sequence_name);or somethign like that?If so, the SELECT may be incrementing the counter and that would explainthe jump by 2 your seeing.There is a function to determine the value of the sequence withoutincrementing for postgres, but I don't remember right now what that is.I actually just did something like this myself. Creating an entry in atable and then needing to find out what the entry id was. In my case, Iactually ended up just doing a SELECT with a where clause including thedata I just inserted, reverse sorted by record creation date (timestampdefault now() kind of thing, not included in INSERT statement) with alimit of 1.I know I could have used the function
to get the sequence value, but Iwasn't absolutely sure what would happen. If two processes incremented thesequence at the same time, what would the function return, the valuefor that connection's insert, or the value of the other session?Especially when I added Apache::DBI to the mix where db connections appearto be pooled and shared. This way I know I'm getting the value I'm lookingfor.Gregwww.bluewolverine.com
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
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: Preloading DBI crashes Apache
Dan Brosemer wrote: Here's the thread to date: http://marc.theaimsgroup.com/?l=apache-modperlm=104586287823510w=2 On Sun, Feb 23, 2003 at 10:27:22AM -0500, Dan Brosemer wrote: On Sun, Feb 23, 2003 at 04:35:39AM -0800, Ask Bjoern Hansen wrote: Hi. I'm new here, and hoping someone can help me. I've installed the latest -current version of OpenBSD, and loaded mod_perl as a DSO. That gets me Apache 1.3.27, Perl 5.8.0, and mod_perl 1.27. The plot thickens. Loading mod_perl statically gets rid of this problem. Even with otherwise-identical configure arguments. Yet, the DSO mod_perl works fine except when I preload DBI. I'm _quite_ confused. I'd really like the DSO method to work, as then I wouldn't have to modify the OpenBSD source tree (any more than I normally do, anyway). Does anyone have suggestions? This sounds kind of similar to some problems I had on Debian. Try a groups.google.com search for author of 'Keith G. Murphy' and subject of Memory leak on reload when the 'Pg' driver is preloaded or even Apache segfaulting upon perl module load. I gave up on it quite some time ago and started using the statically linked mod_perl.
Re: Preloading DBI crashes Apache
On Wed, Feb 26, 2003 at 01:09:46AM -0500, Dan Brosemer wrote: Here's the thread to date: http://marc.theaimsgroup.com/?l=apache-modperlm=104586287823510w=2 helo; I am seeing problems with mod_perl in OpenBSD 3.2 chroot env. This has me twiddling my thumbs after tailing my error_log:) Anyways it is obviously something to do with the chroot. If I start apache with httpd -u (non-chrooted dso) Then everything works fine. To test I try a simple mod_perl module, as well as try the env cgi tests in /cgi-bin . Then when I chroot the mod_perl simple test works however any /cgi-bin .pl or .cgi do not work. The chroot / is /var/www whereas the /cgi-bin is /var/www/cgi-bin Did you find something occuring like that as well? Maybe it something obvious that I staring @ but I don't see it and would appreciate a clue stick. (If one is handy.) ;-) Best Regards, [EMAIL PROTECTED] -- /* Security is a work in progress - dreamwvr */ # # Note: To begin Journey type man afterboot,man help,man hier[.] # // Who's Afraid of Schrodinger's Cat? /var/(.)?mail/me \? ;-]
Re: Preloading DBI crashes Apache
On Wed, Feb 26, 2003 at 11:45:32AM -0700, [EMAIL PROTECTED] wrote: On Wed, Feb 26, 2003 at 01:09:46AM -0500, Dan Brosemer wrote: Here's the thread to date: http://marc.theaimsgroup.com/?l=apache-modperlm=104586287823510w=2 helo; I am seeing problems with mod_perl in OpenBSD 3.2 chroot env. This has me twiddling my thumbs after tailing my error_log:) Anyways it is obviously something to do with the chroot. If I start apache with httpd -u (non-chrooted dso) Then everything works fine. To test I try a simple mod_perl module, as well as try the env cgi tests in /cgi-bin . Then when I chroot the mod_perl simple test works however any /cgi-bin .pl or .cgi do not work. The chroot / is /var/www whereas the /cgi-bin is /var/www/cgi-bin Did you find something occuring like that as well? Maybe it something obvious that I staring @ but I don't see it and would appreciate a clue stick. (If one is handy.) ;-) This is not the problem I'm seeing at all. You'll note from this thread http://monkey.org/openbsd/archive/misc/0302/msg01943.html that I see this same problem when using the sources from apache.org (no chroot available to be a problem). It seems related to compiling mod_perl as DSO and nothing else. To correct the problem you're seeing, I found it useful to make /var/www/var/www a symlink to / This simplifies a lot of things with the loss of only a little elegance. HTH. -Dan -- Burnished gallows set with red Caress the fevered, empty mind Of man who hangs bloodied and blind To reach for wisdom, not for bread. -- Deoridhe Grimsdaughter
Re: Preloading DBI crashes Apache
On Wed, Feb 26, 2003 at 02:05:24PM -0500, Dan Brosemer wrote:
This is not the problem I'm seeing at all. You'll note from this thread
http://monkey.org/openbsd/archive/misc/0302/msg01943.html
that I see this same problem when using the sources from apache.org (no
chroot available to be a problem).
It seems related to compiling mod_perl as DSO and nothing else.
To correct the problem you're seeing, I found it useful to make
/var/www/var/www a symlink to /
tried it. It did not work. What happens is the same /var/www/cgi-bin
is used by httpd when in chroot or not. The error is the notorious
Premature end of Script headers.. Which occurs only in chroot env.
chown to www.www doesn't make any diff the chmod will be the same.
Appreciate the solution although it didn't work for me.
before I forget for this wanting to apache in chroot w/startup.pl
Here is a snippit for those using startup.pl in chroot that works ..
#!/usr/bin/perl
#modify the include path before we do anything
BEGIN {
use Apache ();
use lib Apache-server_root_relative('/lib/perl');
## Note:
# in chroot env server_root_relative is absolute from chroot /
##
}
I am starting to think it is not too practical running apache chrooted
at this time. I had thought that once the libs were in place etc
everything would work exactly the same. ;-}
Well off to parse the dso stuff. I might be real sorry I sed that;-)
Best Regards,
[EMAIL PROTECTED]
--
/* Security is a work in progress - dreamwvr */
#
# Note: To begin Journey type man afterboot,man help,man hier[.]
#
// Who's Afraid of Schrodinger's Cat? /var/(.)?mail/me \? ;-]
Re: Preloading DBI crashes Apache
Here's the thread to date: http://marc.theaimsgroup.com/?l=apache-modperlm=104586287823510w=2 On Sun, Feb 23, 2003 at 10:27:22AM -0500, Dan Brosemer wrote: On Sun, Feb 23, 2003 at 04:35:39AM -0800, Ask Bjoern Hansen wrote: Hi. I'm new here, and hoping someone can help me. I've installed the latest -current version of OpenBSD, and loaded mod_perl as a DSO. That gets me Apache 1.3.27, Perl 5.8.0, and mod_perl 1.27. The plot thickens. Loading mod_perl statically gets rid of this problem. Even with otherwise-identical configure arguments. Yet, the DSO mod_perl works fine except when I preload DBI. I'm _quite_ confused. I'd really like the DSO method to work, as then I wouldn't have to modify the OpenBSD source tree (any more than I normally do, anyway). Does anyone have suggestions? Even pointers for where in the code to look would be much appreciated. TIA. -Dan -- Burnished gallows set with red Caress the fevered, empty mind Of man who hangs bloodied and blind To reach for wisdom, not for bread. -- Deoridhe Grimsdaughter
Re: Preloading DBI crashes Apache
On Fri, 21 Feb 2003, Dan Brosemer wrote: Hi. I'm new here, and hoping someone can help me. I've installed the latest -current version of OpenBSD, and loaded mod_perl as a DSO. That gets me Apache 1.3.27, Perl 5.8.0, and mod_perl 1.27. [...] These are taken using DBD::mysql. I'd be happy to provide backtraces using other modules if they'd be useful to someone debugging. [...] A backtrace with DBD::mysqlPP would be fun. Have you upgraded mysql after you last installed DBD::mysql? Did DBD::mysql pass all tests when you installed it? - ask -- ask bjoern hansen, http://www.askbjoernhansen.com/ !try; do();
Re: Preloading DBI crashes Apache
On Sun, Feb 23, 2003 at 04:35:39AM -0800, Ask Bjoern Hansen wrote: On Fri, 21 Feb 2003, Dan Brosemer wrote: Hi. I'm new here, and hoping someone can help me. I've installed the latest -current version of OpenBSD, and loaded mod_perl as a DSO. That gets me Apache 1.3.27, Perl 5.8.0, and mod_perl 1.27. [...] These are taken using DBD::mysql. I'd be happy to provide backtraces using other modules if they'd be useful to someone debugging. [...] A backtrace with DBD::mysqlPP would be fun. You're right, it _is_ fun... :) (gdb) bt #0 0x403ea000 in ?? () #1 0x40380041 in Perl_runops_standard () #2 0x403627d0 in Perl_call_sv () #3 0x4036255a in Perl_call_sv () #4 0x402b4ada in perl_call_handler (sv=0x28615c, r=0x6c5034, args=0x0) at mod_perl.c:1658 #5 0x402b3e8d in perl_run_stacked_handlers (hook=0x402af439 PerlHandler, r=0x6c5034, handlers=0x283b9c) at mod_perl.c:1371 #6 0x402b1a2b in perl_handler (r=0x6c5034) at mod_perl.c:897 #7 0x49ca1 in ap_invoke_handler (r=0x6c5034) at http_config.c:520 #8 0x69d4c in process_request_internal (r=0x6c5034) at http_request.c:1308 #9 0x69db6 in ap_process_request (r=0x6c5034) at http_request.c:1324 #10 0x5c88b in child_main (child_num_arg=0) at http_main.c:4708 #11 0x5cab1 in make_child (s=0xd3034, slot=0, now=1046013324) at http_main.c:4832 #12 0x5cc2a in startup_children (number_to_start=20) at http_main.c:4914 #13 0x5d8a4 in standalone_main (argc=2, argv=0xcfbfdb04) at http_main.c:5272 #14 0x5e298 in main (argc=2, argv=0xcfbfdb04) at http_main.c:5639 It won't even tell me what file it died in there... #0 seems to have no .so associated with it. Have you upgraded mysql after you last installed DBD::mysql? Did No. This is the initial version of both mysql and postgresql. DBD::mysql pass all tests when you installed it? When I 'make test', Msql-Mysql-modules-1.2219 reports: All tests successful, 1 test and 14 subtests skipped. Since my test program runs fine outside of a webserver, or in mod_perl when DBI isn't preloaded, I'm not surprised. Wouldn't that imply that the problem is in DBI's clone function? I've been staring at _clone_dbis() and related functions for three days now, to no avail, though, so I'm probably wrong. :) Thanks for your help. -Dan -- Burnished gallows set with red Caress the fevered, empty mind Of man who hangs bloodied and blind To reach for wisdom, not for bread. -- Deoridhe Grimsdaughter
Re: Preloading DBI crashes Apache
Hi Dan, i had a similar problem with DBI. Did you reinstall (recompile) the DBI module after you installed Perl 5.80 from a previous Perl version (and maybe all DBD drivers)? Helmut --On Friday, February 21, 2003 16:28:19 -0500 Dan Brosemer [EMAIL PROTECTED] wrote: Hi. I'm new here, and hoping someone can help me. I've installed the latest -current version of OpenBSD, and loaded mod_perl as a DSO. That gets me Apache 1.3.27, Perl 5.8.0, and mod_perl 1.27. Apache starts fine, but when I try to access any script that does DBI-connect(...), it generates a segfault: [Thu Feb 20 14:52:09 2003] [notice] child pid 29135 exit signal Segmentation fault (11) This happens with DBI versions 1.28, 1.30, and 1.32. It happens when DBI is in Pure Perl mode or in XS mode with DBD::mysql, DBD::mysqlPP, DBD::Pg, and DBD::PgPP. It only happens when DBI is pulled in at server startup, though. Either through 'PerlModule DBI' or 'perlrequire startup.perl' and 'use DBI' in startup.perl. I can load other modules (like CGI.pm) at server startup just fine. The same thing happens if I use 'PerlModule SomethingElse' where SomethingElse has a 'use DBI' in it. I'm at my wit's end, so any help would be greatly appreciated. I've pased a backtrace from 'httpd -X' and the script I've been using to test. Thanks in advance for any help. -Dan These are taken using DBD::mysql. I'd be happy to provide backtraces using other modules if they'd be useful to someone debugging. before loading sharedlibrary symbols: (gdb) bt # 0 0x403ea000 in ?? () from # /usr/local/libdata/perl5/site_perl/i386-openbsd/auto/DBD/mysql/mysql.so # 1 0x40337fe5 in ?? () from /usr/lib/libperl.so.8.0 # 2 0x40380041 in ?? () from /usr/lib/libperl.so.8.0 # 3 0x403627d0 in ?? () from /usr/lib/libperl.so.8.0 # 4 0x4036255a in ?? () from /usr/lib/libperl.so.8.0 # 5 0x402b4ada in ?? () from /usr/lib/apache/modules/mod_perl.so # 6 0x402b3e8d in ?? () from /usr/lib/apache/modules/mod_perl.so # 7 0x402b1a2b in ?? () from /usr/lib/apache/modules/mod_perl.so # 8 0x49ca1 in ap_invoke_handler (r=0x6c5034) at http_config.c:520 # 9 0x69d4c in process_request_internal (r=0x6c5034) at # http_request.c:1308 10 0x69db6 in ap_process_request (r=0x6c5034) at # http_request.c:1324 11 0x5c88b in child_main (child_num_arg=0) at # http_main.c:4708 # 12 0x5cab1 in make_child (s=0xd3034, slot=0, now=1045861707) at # http_main.c:4832 13 0x5cc2a in startup_children (number_to_start=20) at # http_main.c:4914 14 0x5d8a4 in standalone_main (argc=2, argv=0xcfbfd838) # at http_main.c:5272 15 0x5e298 in main (argc=2, argv=0xcfbfd838) at # http_main.c:5639 and after (gdb) bt # 0 0x403ea000 in end () # 1 0x403f5d1d in boot_DBD__mysql (cv=0x704354) at mysql.xsi:18 # 2 0x40337fe5 in Perl_pp_entersub () # 3 0x40380041 in Perl_runops_standard () # 4 0x403627d0 in Perl_call_sv () # 5 0x4036255a in Perl_call_sv () # 6 0x402b4ada in perl_call_handler (sv=0x28615c, r=0x6c5034, args=0x0) # at mod_perl.c:1658 7 0x402b3e8d in perl_run_stacked_handlers # (hook=0x402af439 PerlHandler, r=0x6c5034, handlers=0x284b9c) at # mod_perl.c:1371 8 0x402b1a2b in perl_handler (r=0x6c5034) at # mod_perl.c:897 # 9 0x49ca1 in ap_invoke_handler (r=0x6c5034) at http_config.c:520 # 10 0x69d4c in process_request_internal (r=0x6c5034) at # http_request.c:1308 11 0x69db6 in ap_process_request (r=0x6c5034) at # http_request.c:1324 12 0x5c88b in child_main (child_num_arg=0) at # http_main.c:4708 # 13 0x5cab1 in make_child (s=0xd3034, slot=0, now=1045861707) at # http_main.c:4832 14 0x5cc2a in startup_children (number_to_start=20) at # http_main.c:4914 15 0x5d8a4 in standalone_main (argc=2, argv=0xcfbfd838) # at http_main.c:5272 16 0x5e298 in main (argc=2, argv=0xcfbfd838) at # http_main.c:5639 # !/usr/bin/perl -w use CGI; use DBI; use lib '/var/www/localsettings'; use Settings; my $cgi = new CGI; my $dbh = DBI-connect(Settings::dbconnect); print $cgi-header; print EOT; htmlheadtitlefoo/titlebodyConnected/body/html EOT exit 0; -- Burnished gallows set with red Caress the fevered, empty mind Of man who hangs bloodied and blind To reach for wisdom, not for bread. -- Deoridhe Grimsdaughter
Re: Preloading DBI crashes Apache
On Sun, Feb 23, 2003 at 04:26:51PM +0100, Dr. Helmut Zeilinger wrote: Hi Dan, i had a similar problem with DBI. Did you reinstall (recompile) the DBI module after you installed Perl 5.80 from a previous Perl version (and maybe all DBD drivers)? No. This was a fresh install of OpenBSD 3.3-beta (-current) which comes with Perl 5.8.0 and I added mysql, DBI, DBD::*, and mod_perl after the fact. So there was no previous Perl version to have DBI compiled for and lying around. Thanks. -Dan -- Burnished gallows set with red Caress the fevered, empty mind Of man who hangs bloodied and blind To reach for wisdom, not for bread. -- Deoridhe Grimsdaughter
Preloading DBI crashes Apache
Hi. I'm new here, and hoping someone can help me. I've installed the latest -current version of OpenBSD, and loaded mod_perl as a DSO. That gets me Apache 1.3.27, Perl 5.8.0, and mod_perl 1.27. Apache starts fine, but when I try to access any script that does DBI-connect(...), it generates a segfault: [Thu Feb 20 14:52:09 2003] [notice] child pid 29135 exit signal Segmentation fault (11) This happens with DBI versions 1.28, 1.30, and 1.32. It happens when DBI is in Pure Perl mode or in XS mode with DBD::mysql, DBD::mysqlPP, DBD::Pg, and DBD::PgPP. It only happens when DBI is pulled in at server startup, though. Either through 'PerlModule DBI' or 'perlrequire startup.perl' and 'use DBI' in startup.perl. I can load other modules (like CGI.pm) at server startup just fine. The same thing happens if I use 'PerlModule SomethingElse' where SomethingElse has a 'use DBI' in it. I'm at my wit's end, so any help would be greatly appreciated. I've pased a backtrace from 'httpd -X' and the script I've been using to test. Thanks in advance for any help. -Dan These are taken using DBD::mysql. I'd be happy to provide backtraces using other modules if they'd be useful to someone debugging. before loading sharedlibrary symbols: (gdb) bt #0 0x403ea000 in ?? () from /usr/local/libdata/perl5/site_perl/i386-openbsd/auto/DBD/mysql/mysql.so #1 0x40337fe5 in ?? () from /usr/lib/libperl.so.8.0 #2 0x40380041 in ?? () from /usr/lib/libperl.so.8.0 #3 0x403627d0 in ?? () from /usr/lib/libperl.so.8.0 #4 0x4036255a in ?? () from /usr/lib/libperl.so.8.0 #5 0x402b4ada in ?? () from /usr/lib/apache/modules/mod_perl.so #6 0x402b3e8d in ?? () from /usr/lib/apache/modules/mod_perl.so #7 0x402b1a2b in ?? () from /usr/lib/apache/modules/mod_perl.so #8 0x49ca1 in ap_invoke_handler (r=0x6c5034) at http_config.c:520 #9 0x69d4c in process_request_internal (r=0x6c5034) at http_request.c:1308 #10 0x69db6 in ap_process_request (r=0x6c5034) at http_request.c:1324 #11 0x5c88b in child_main (child_num_arg=0) at http_main.c:4708 #12 0x5cab1 in make_child (s=0xd3034, slot=0, now=1045861707) at http_main.c:4832 #13 0x5cc2a in startup_children (number_to_start=20) at http_main.c:4914 #14 0x5d8a4 in standalone_main (argc=2, argv=0xcfbfd838) at http_main.c:5272 #15 0x5e298 in main (argc=2, argv=0xcfbfd838) at http_main.c:5639 and after (gdb) bt #0 0x403ea000 in end () #1 0x403f5d1d in boot_DBD__mysql (cv=0x704354) at mysql.xsi:18 #2 0x40337fe5 in Perl_pp_entersub () #3 0x40380041 in Perl_runops_standard () #4 0x403627d0 in Perl_call_sv () #5 0x4036255a in Perl_call_sv () #6 0x402b4ada in perl_call_handler (sv=0x28615c, r=0x6c5034, args=0x0) at mod_perl.c:1658 #7 0x402b3e8d in perl_run_stacked_handlers (hook=0x402af439 PerlHandler, r=0x6c5034, handlers=0x284b9c) at mod_perl.c:1371 #8 0x402b1a2b in perl_handler (r=0x6c5034) at mod_perl.c:897 #9 0x49ca1 in ap_invoke_handler (r=0x6c5034) at http_config.c:520 #10 0x69d4c in process_request_internal (r=0x6c5034) at http_request.c:1308 #11 0x69db6 in ap_process_request (r=0x6c5034) at http_request.c:1324 #12 0x5c88b in child_main (child_num_arg=0) at http_main.c:4708 #13 0x5cab1 in make_child (s=0xd3034, slot=0, now=1045861707) at http_main.c:4832 #14 0x5cc2a in startup_children (number_to_start=20) at http_main.c:4914 #15 0x5d8a4 in standalone_main (argc=2, argv=0xcfbfd838) at http_main.c:5272 #16 0x5e298 in main (argc=2, argv=0xcfbfd838) at http_main.c:5639 #!/usr/bin/perl -w use CGI; use DBI; use lib '/var/www/localsettings'; use Settings; my $cgi = new CGI; my $dbh = DBI-connect(Settings::dbconnect); print $cgi-header; print EOT; htmlheadtitlefoo/titlebodyConnected/body/html EOT exit 0; -- Burnished gallows set with red Caress the fevered, empty mind Of man who hangs bloodied and blind To reach for wisdom, not for bread. -- Deoridhe Grimsdaughter
Urgent: DBI::Auth configuration problem
This is the last piece in my implementation. If anyone can help with how to debug this or what is wrong with my configuration, I'd really appreciate it! I'm trying DBI::Auth against a Postgresql database for authentication. It's not working. My postgres debug log shows no activity as well as this error regarding my configuration. I don't know how to debug this. Anyone able to help? Error Log from Apache shows: [Tue Feb 18 16:13:53 2003] [notice] Apache/1.3.27 (Unix) Embperl/2.0b8 mod_perl/1.27 configured -- resuming normal operations [Tue Feb 18 16:13:53 2003] [notice] Accept mutex: sysvsem (Default: sysvsem) [Tue Feb 18 16:14:03 2003] [error] [client 192.168.0.121] client denied by server configuration: /www/htdocs/tester/index.html Steps I went through to install the web server (RedHat 7.3 install from source): installed Apache::AuthDBI off CPAN. Recompiled mod_perl and apache: perl Makefile.PL DO_HTTPD=1 USE_APACI=1 APACHE_PREFIX=/www PERL_AUTHEN=1 PERL_AUTHZ=1 PERL_CLEANUP=1 PERL_STACKED_HANDLERS=1 make/make install worked great. Web server works. I can access Posgresql just fine using Perl DBI. The .htaccess file in /www/htdocs/tester: AuthType Basic AuthName DBI require user scott Here's the relevant entries in my httpd.conf file: Directory / Options FollowSymLinks AllowOverride None /Directory Directory /www/htdocs Options Indexes FollowSymLinks MultiViews AllowOverride All Order allow,deny Deny from all /Directory PerlModule Embperl PerlSetEnv EMBPERL_SESSION_HANDLER_CLASS no PerlSetEnv EMBPERL_DEBUG 10477 PerlSetEnv EMBPERL_DEBUG 0x7fff PerlSetEnv EMBPERL_VIRTLOG /embperl/log PerlSetEnv EMBPERL_OPTIONS 8208 # optRawInput = 16 # optAllFormData = 8192 PerlModule Embperl::Object PerlModule Apache::DBI # PerlModule MD5 Location /embperl/log SetHandler perl-script PerlHandler HTML::Embperl Options ExecCGI /Location Files *.epl PerlSetEnv EMBPERL_APPNAME my_embperl_app PerlSetEnv EMBPERL_OBJECT_BASE base.epl PerlSetEnv EMBPERL_ESCMODE 0 # PerlSetEnv EMBPERL_FILESMATCH \.htm.?|\.epl$ PerlSetEnv EMBPERL_FILESMATCH \.epl$ SetHandler perl-script PerlHandler Embperl::Object # PerlHandler HTML::Embperl Options ExecCGI /Files AddType text/html .epl Directory /www/cgi-bin/webcal AllowOverride AuthConfig Options ExecCGI /Directory PerlModule Apache::AuthDBI PerlAuthzHandler Apache::AuthDBI::authz PerlAuthenHandler Apache::AuthDBI::authen PerlSetVar Auth_DBI_data_source dbi:Pg:dbname=webautomation PerlSetVar Auth_DBI_username webuser PerlSetVar Auth_DBI_password password PerlSetVar Auth_DBI_pwd_table users PerlSetVar Auth_DBI_uid_field username PerlSetVar Auth_DBI_pwd_field password PerlSetVar Auth_DBI_grp_table groups PerlSetVar Auth_DBI_grp_field groupname PerlSetVar Auth_DBI_encrypted off Thanks! Scott
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
DBI::Auth configuration problem
I'm trying DBI::Auth against a Postgresql database for authentication. It's not working. My postgres debug log shows no activity as well as this error regarding my configuration. I don't know how to debug this. Anyone able to help? Error Log from Apache shows: [Tue Feb 18 16:13:53 2003] [notice] Apache/1.3.27 (Unix) Embperl/2.0b8 mod_perl/1.27 configured -- resuming normal operations [Tue Feb 18 16:13:53 2003] [notice] Accept mutex: sysvsem (Default: sysvsem) [Tue Feb 18 16:14:03 2003] [error] [client 192.168.0.121] client denied by server configuration: /www/htdocs/tester/index.html Steps I went through to install the web server (RedHat 7.3 install from source): installed Apache::AuthDBI off CPAN. Recompiled mod_perl and apache: perl Makefile.PL DO_HTTPD=1 USE_APACI=1 APACHE_PREFIX=/www PERL_AUTHEN=1 PERL_AUTHZ=1 PERL_CLEANUP=1 PERL_STACKED_HANDLERS=1 make/make install worked great. Web server works. I can access Posgresql just fine using Perl DBI. The .htaccess file in /www/htdocs/tester: AuthType Basic AuthName DBI require user scott Here's the relevant entries in my httpd.conf file: Directory / Options FollowSymLinks AllowOverride None /Directory Directory /www/htdocs Options Indexes FollowSymLinks MultiViews AllowOverride All Order allow,deny Deny from all /Directory PerlModule Embperl PerlSetEnv EMBPERL_SESSION_HANDLER_CLASS no PerlSetEnv EMBPERL_DEBUG 10477 PerlSetEnv EMBPERL_DEBUG 0x7fff PerlSetEnv EMBPERL_VIRTLOG /embperl/log PerlSetEnv EMBPERL_OPTIONS 8208 # optRawInput = 16 # optAllFormData = 8192 PerlModule Embperl::Object PerlModule Apache::DBI # PerlModule MD5 Location /embperl/log SetHandler perl-script PerlHandler HTML::Embperl Options ExecCGI /Location Files *.epl PerlSetEnv EMBPERL_APPNAME my_embperl_app PerlSetEnv EMBPERL_OBJECT_BASE base.epl PerlSetEnv EMBPERL_ESCMODE 0 # PerlSetEnv EMBPERL_FILESMATCH \.htm.?|\.epl$ PerlSetEnv EMBPERL_FILESMATCH \.epl$ SetHandler perl-script PerlHandler Embperl::Object # PerlHandler HTML::Embperl Options ExecCGI /Files AddType text/html .epl Directory /www/cgi-bin/webcal AllowOverride AuthConfig Options ExecCGI /Directory PerlModule Apache::AuthDBI PerlAuthzHandler Apache::AuthDBI::authz PerlAuthenHandler Apache::AuthDBI::authen PerlSetVar Auth_DBI_data_source dbi:Pg:dbname=webautomation PerlSetVar Auth_DBI_username webuser PerlSetVar Auth_DBI_password password PerlSetVar Auth_DBI_pwd_table users PerlSetVar Auth_DBI_uid_field username PerlSetVar Auth_DBI_pwd_field password PerlSetVar Auth_DBI_grp_table groups PerlSetVar Auth_DBI_grp_field groupname PerlSetVar Auth_DBI_encrypted off Thanks! Scott
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^)
Use DBI in http.conf
Has anyone any information on success/horror stories for using DBI in apache config files. I have a number of PerlModule Library::Module Location '/Module' SetHandler Perl-Script PerlHandler Library::Module /Location Type configs. I can very easily extract this information from a database. Is using DBI within a perl directive a good idea... perhaps there is a more elligant way of getting the information. Would gladly welcome references to things I should read. Just casting a line as I don't have a lot of research time available. Cheers, Wes
Re: Use DBI in http.conf
Wes Cravens wrote: I have a number of PerlModule Library::Module Location '/Module' SetHandler Perl-Script PerlHandler Library::Module /Location Type configs. I can very easily extract this information from a database. Or you could use Apache::Dispatch, or you could put them in a simple text file, or you could use mod_macro. I'm sure it would work to put them in DBI (although you'd better close that connection before Apache forks!), but then you have a bunch of config data that can only be changed by messing with SQL and can no longer be easilly viewed, diffed, versioned, etc. - Perrin
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
DBI Mod_perl2
Should I expect DBI to work with mod_perl2? I have a simple script that just connects to a MySQL database and reports success or faiure. When I run it from cgi-bin as a regular CGI script, it succeeds. When I put it in my mod_perl script directory, it runs, but fails to connect. My mod_perl directory is configured as: Alias /cgi /usr/local/apache2/perl Location /cgi SetHandlerperl-script PerlResponseHandler ModPerl::Registry PerlOptions +ParseHeaders /Location The script is named dbi.pl. Thus, http://localhost/cgi-bin/dbi.pl connects okay, but http://localhost/cgi/dbi.pl fails to connect -- Daryl Lee Open the present--it's a gift.
Re: DBI Mod_perl2
Daryl Lee wrote: Should I expect DBI to work with mod_perl2? I have a simple script that just connects to a MySQL database and reports success or faiure. When I run it from cgi-bin as a regular CGI script, it succeeds. When I put it in my mod_perl script directory, it runs, but fails to connect. My mod_perl directory is configured as: Alias /cgi /usr/local/apache2/perl Location /cgi SetHandlerperl-script PerlResponseHandler ModPerl::Registry PerlOptions +ParseHeaders /Location The script is named dbi.pl. Thus, http://localhost/cgi-bin/dbi.pl connects okay, but http://localhost/cgi/dbi.pl fails to connect Should work just fine, but you need the latest DBI version. I believe 1.31 (but 1.32 is out). Does anybody remember the exact version required, I don't see anything relevant in the Changes file. I've added this item to the troubleshooting version. If the problem persists please send a complete report as explained here: http://perl.apache.org/docs/2.0/user/help/help.html#Reporting_Problems and attach the the shortest possible version of the script that still reproduces the problem. __ 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
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
