Re: Can't find Apache::DBI on Win32 version
Hi At 06:24 PM 7/4/00 +0100, David Mitchell wrote: > > This worked but now I get upon start up of the apache httpd daemon: > > > > defined(@array) is deprecated at c:/Perl/site/5.6.0/lib/Apache/DBI.pm > > > > line 135 (Maybe you should just omit the defined()?) > >Just edit c:/Perl/site/5.6.0/lib/Apache/DBI.pm, deleting the 'defined' >on line 135 :-) I did look and its not so obvious what to comment out without mucking the file ... Does anyone else have this one installed and had the same problem I had. I'm using the win32 version by Randy Kobes. Thanks David
Re: Can't find Apache::DBI on Win32 version
> This worked but now I get upon start up of the apache httpd daemon: > > defined(@array) is deprecated at c:/Perl/site/5.6.0/lib/Apache/DBI.pm > > line 135 (Maybe you should just omit the defined()?) Just edit c:/Perl/site/5.6.0/lib/Apache/DBI.pm, deleting the 'defined' on line 135 :-)
Re: Can't find Apache::DBI on Win32 version
Hi, At 03:30 PM 7/3/00 -0500, Randy Kobes wrote: >http://www.perl.com/CPAN/authors/id/M/ME/MERGL/, >unpack it, and run >perl Makefile.PL >nmake >nmake install >If you don't have nmake, you can get a self-extracting archive >from ftp://ftp.microsoft.com/softlib/MSLFILES/nmake15.exe. This worked but now I get upon start up of the apache httpd daemon: defined(@array) is deprecated at c:/Perl/site/5.6.0/lib/Apache/DBI.pm line 135 (Maybe you should just omit the defined()?) I didn't find this. Any ideas what to do . Thanks. David
Re: Can't find Apache::DBI on Win32 version
Randy Kobes wrote: > > On Mon, 3 Jul 2000, David Jourard wrote: > > > Hi, > > > > I'm running the win32 version. > > I changed the httpd.conf file to include: Apache::DBI > > I get that it cannot be found. > [ ... ] > > Apache::DBI doesn't need a C compiler to install, so you > should be able to just do >c:\> perl -MCPAN -e shell >cpan> install Apache::DBI > Or, alternatively, get the distribution from > http://www.perl.com/CPAN/authors/id/M/ME/MERGL/, > unpack it, and run >perl Makefile.PL >nmake >nmake install > If you don't have nmake, you can get a self-extracting archive > from ftp://ftp.microsoft.com/softlib/MSLFILES/nmake15.exe. [ ... ] Then, If you are using AuthDBI.pm you'll need to comment out lines 6 & 7 (use IPC::SysV and use strict) Well, thats what I needed to do anyway. YMMV Daniel
Re: apache::DBI
Kristopher Lalletti <[EMAIL PROTECTED]> writes: > Okay, so if it seems that Redhat 6.1/6.2 Apache & mod_perl is broken.. > Anyone have a good guide/website to get apache & mod_perl compiled > properly? http://perl.apache.org/guide/install.html#Installing_mod_perl_in_10_Minute > I've been reading the fine manuals and compiled httpd with mod_perl (by > using the Makefile.PL from the mod_perl src tree.) I have to say that RH6.2 and mod_perl "works for me" out of the box, at least in development. I'll let you know what it's like in production in a few weeks... ;-) You have all this carp in your httpd.conf? What does "apachectl configtest" tell you? LoadModule perl_modulemodules/libperl.so AddModule mod_perl.c PerlRequire startup.pl Alias /perl/ /home/httpd/perl/ SetHandler perl-script PerlHandler Apache::Registry Options +ExecCGI -- Dave Hodgkinson, http://www.hodgkinson.org Editor-in-chief, The Highway Star http://www.deep-purple.com Apache, mod_perl, MySQL, Sybase hired gun for, well, hire -
RE: apache::DBI
Okay, so if it seems that Redhat 6.1/6.2 Apache & mod_perl is broken.. Anyone have a good guide/website to get apache & mod_perl compiled properly? I've been reading the fine manuals and compiled httpd with mod_perl (by using the Makefile.PL from the mod_perl src tree.) When I list the modules compiled in the httpd, I do see the mod_perl.c , however, trying to get the server up and running just fails. It does the same thing as I would add the keyword PerlModule Apache::DBI in the httpd.conf from the out-of-the-box apache & mod_perl from redhat 6.2 (the httpd seems to load, but it dies, because I'm unable to telnet on port 80 and there are no logs of the crash). Help? -Original Message- From: Guo Bin [mailto:[EMAIL PROTECTED]] Sent: July 2, 2000 9:18 PM To: Christopher Suarez; [EMAIL PROTECTED] Subject: Re: apache::DBI Though not using rh 6.2, my experience on 6.1 was the same --- apache will crash whenever use Apache::DBI is included in httpd.conf. I'm now using manually compiled apache and modperl and they are working fine. Hope this will also work for 6.2. On small glitch, Apache::Status cannot show Apache::DBI connections on rh 6.1 i386, while the same setting works on a rh 6.1 sparc! -- Guo Bin --- Christopher Suarez <[EMAIL PROTECTED]> wrote: > I'm running rh linux 6.2 on a laptop and have tried for > sometime to get > apache::DBI runnning. > > modperl wokrs fine with apache but when I add the line > > PerlModule Apache::DBI to srm.conf, httpd.conf or "use > Apache::DBI" to > startup.pl and then PerlRequire /path/startup.pl to > httpd.conf it won't > work. apache will start ok(saying it's using mod_perl) > but won't shut down > ok and error_log doesn't > say anythings wrong. > the webserver won't response on contacting 127.0.0.1 in a > browser it'll > response connection refused. > > versions: > > apache-1.3.12-2 > apache-devel-1.3.12-2 > perl-2.00503-10 > perl-DBI-1.13-1 > perl-DBD-msql-mysql-1.2210-1 > perl-Apache-DBI-0.01-2 > perl-Apache-DBILogin-1.5-2 > perl-Apache-DBILogger-0.93-2 > perl-Apache-RedirectDBI-0.01-2 > mod_perl-1.21-10 > strange??? > __ Do You Yahoo!? Kick off your party with Yahoo! Invites. http://invites.yahoo.com/
Re: Can't find Apache::DBI on Win32 version
On Mon, 3 Jul 2000, David Jourard wrote: > Hi, > > I'm running the win32 version. > I changed the httpd.conf file to include: Apache::DBI > I get that it cannot be found. [ ... ] Apache::DBI doesn't need a C compiler to install, so you should be able to just do c:\> perl -MCPAN -e shell cpan> install Apache::DBI Or, alternatively, get the distribution from http://www.perl.com/CPAN/authors/id/M/ME/MERGL/, unpack it, and run perl Makefile.PL nmake nmake install If you don't have nmake, you can get a self-extracting archive from ftp://ftp.microsoft.com/softlib/MSLFILES/nmake15.exe. best regards, randy kobes
Can't find Apache::DBI on Win32 version
Hi, I'm running the win32 version. I changed the httpd.conf file to include: Apache::DBI I get that it cannot be found. I"ve setup the path inside httpd file as push @INC,qw(c:/perl/site/5.6.0/lib c:/perl/5.6.0/lib c:/perl/5.6.0/lib/MSWin32-x86 c:/perl/5.6.0/lib c:/perl/site/5.6.0/lib/MSWin32-x86 c:/perl/site/5.6.0/lib ); Does anyone know what the quick fix is. Can I just drop this perl module in. Also I tried to find it but couldn't. Thanks David
Re: apache::DBI
Though not using rh 6.2, my experience on 6.1 was the same --- apache will crash whenever use Apache::DBI is included in httpd.conf. I'm now using manually compiled apache and modperl and they are working fine. Hope this will also work for 6.2. On small glitch, Apache::Status cannot show Apache::DBI connections on rh 6.1 i386, while the same setting works on a rh 6.1 sparc! -- Guo Bin --- Christopher Suarez <[EMAIL PROTECTED]> wrote: > I'm running rh linux 6.2 on a laptop and have tried for > sometime to get > apache::DBI runnning. > > modperl wokrs fine with apache but when I add the line > > PerlModule Apache::DBI to srm.conf, httpd.conf or "use > Apache::DBI" to > startup.pl and then PerlRequire /path/startup.pl to > httpd.conf it won't > work. apache will start ok(saying it's using mod_perl) > but won't shut down > ok and error_log doesn't > say anythings wrong. > the webserver won't response on contacting 127.0.0.1 in a > browser it'll > response connection refused. > > versions: > > apache-1.3.12-2 > apache-devel-1.3.12-2 > perl-2.00503-10 > perl-DBI-1.13-1 > perl-DBD-msql-mysql-1.2210-1 > perl-Apache-DBI-0.01-2 > perl-Apache-DBILogin-1.5-2 > perl-Apache-DBILogger-0.93-2 > perl-Apache-RedirectDBI-0.01-2 > mod_perl-1.21-10 > strange??? > __ Do You Yahoo!? Kick off your party with Yahoo! Invites. http://invites.yahoo.com/
apache::DBI
I'm running rh linux 6.2 on a laptop and have tried for sometime to get apache::DBI runnning. modperl wokrs fine with apache but when I add the line PerlModule Apache::DBI to srm.conf, httpd.conf or "use Apache::DBI" to startup.pl and then PerlRequire /path/startup.pl to httpd.conf it won't work. apache will start ok(saying it's using mod_perl) but won't shut down ok and error_log doesn't say anythings wrong. the webserver won't response on contacting 127.0.0.1 in a browser it'll response connection refused. versions: apache-1.3.12-2 apache-devel-1.3.12-2 perl-2.00503-10 perl-DBI-1.13-1 perl-DBD-msql-mysql-1.2210-1 perl-Apache-DBI-0.01-2 perl-Apache-DBILogin-1.5-2 perl-Apache-DBILogger-0.93-2 perl-Apache-RedirectDBI-0.01-2 mod_perl-1.21-10 strange???
Re: Apache::DBI
> But I run apache I get: > utechnology# ./apachectl start > defined(@array) is deprecated at > /usr/local/lib/perl5/site_perl/5.6.0/Apache/DBI.pm line 135. > (Maybe you should just omit the defined()?) > ./apachectl start: httpd started Perl 5.6.0 has introduced a new warning when it sees code like if (defined @array) ... which is technically wrong, and should be changed to if (@array) ... A suprising number of Perl modules have got code like this in them; it is usually just a simple matter of editing the offending lines. Over time, I should imagine that the various module owners will release new versions that dont generate this warning. * Dave Mitchell, Operations Manager, * Fretwell-Downing Facilities Ltd, UK. [EMAIL PROTECTED] * Tel: +44 114 281 6113.The usual disclaimers * * Standards (n). Battle insignia or tribal totems
Apache::DBI
FreeBSD-3.4stable, apache-1.3.12+mod_perl I use in startup file: use Apache::DBI (); But I run apache I get: utechnology# ./apachectl start defined(@array) is deprecated at /usr/local/lib/perl5/site_perl/5.6.0/Apache/DBI.pm line 135. (Maybe you should just omit the defined()?) ./apachectl start: httpd started Whats this? I'ts strange. How to get Apache::DBI works? Thx Ruslan
Re: DBI connect_cached vs Apache::DBI
connect_cached() does not ignore disconnect(). A disconnect() will remove the dbh from the cache. I ran into odd problems using both (a mistake at the time) connect_cached() and Apache::DBI under mod_perl. -j On Tue, Jun 20, 2000 at 11:22:48AM -0700, Perrin Harkins wrote: > On Tue, 20 Jun 2000, Andrew Dunstan wrote: > > What are the differences? > Apache::DBI uses a cleanup handler to rollback any uncomitted transactions > after each request. It is also transparent, i.e. you can use normal > connect statements and turn the persistence on or off by putting in > Apache::DBI or not. > > There are probably other differences that I'm not aware of. > > - Perrin
RE: Apache::DBI
On Wed, 21 Jun 2000, Eric Jain wrote: > > > Is it be possible to modify Apache::DBI in sich a way that only > > > database connections specified in a PerlRequired startup.pl with > > > Apache::DBI->connect_on_init(...) are stored and all subsequent > > > DBI->connect(...) connections are properly established > > (if no matching > > > stored connection is available), but not stored afterwards? > > > > I'm not sure why you would want to do such a thing, but I > > don't think it > > fits with DBI/Apache::DBI's model... > > > > why exactly are you looking for this behavior? > > Currently I don't use Apache::DBI, even though 99% of all connections > are made as the same user, since I have a few users log in and connect > with their own usernames. This would lead to every process having > several open connections, using up lots of precious RAM... If you just want a quick hack to make this work, you could put in a quick check in the connect method of Apache::DBI which would skip caching connections that use a username other than one you specify in your startup.pl. Should be easy to implement. - Perrin
RE: Apache::DBI
> > Is it be possible to modify Apache::DBI in sich a way that only > > database connections specified in a PerlRequired startup.pl with > > Apache::DBI->connect_on_init(...) are stored and all subsequent > > DBI->connect(...) connections are properly established > (if no matching > > stored connection is available), but not stored afterwards? > > I'm not sure why you would want to do such a thing, but I > don't think it > fits with DBI/Apache::DBI's model... > > why exactly are you looking for this behavior? Currently I don't use Apache::DBI, even though 99% of all connections are made as the same user, since I have a few users log in and connect with their own usernames. This would lead to every process having several open connections, using up lots of precious RAM... -- Eric Jain
RE: Apache::DBI
> -Original Message- > From: Eric Jain [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, June 21, 2000 1:30 PM > To: Mod_Perl > Subject: Apache::DBI > > > Is it be possible to modify Apache::DBI in sich a way that only > database connections specified in a PerlRequired startup.pl with > Apache::DBI->connect_on_init(...) are stored and all subsequent > DBI->connect(...) connections are properly established (if no matching > stored connection is available), but not stored afterwards? I'm not sure why you would want to do such a thing, but I don't think it fits with DBI/Apache::DBI's model... why exactly are you looking for this behavior? --Geoff > Or could > Apache::DBI::db::disconnect be changed, so it would actually > disconnect, except if it was handling one of the connect_on_init > connections? > > > -- > Eric Jain >
Apache::DBI
Is it be possible to modify Apache::DBI in sich a way that only database connections specified in a PerlRequired startup.pl with Apache::DBI->connect_on_init(...) are stored and all subsequent DBI->connect(...) connections are properly established (if no matching stored connection is available), but not stored afterwards? Or could Apache::DBI::db::disconnect be changed, so it would actually disconnect, except if it was handling one of the connect_on_init connections? -- Eric Jain
Re: DBI connect_cached vs Apache::DBI
On Tue, 20 Jun 2000, Andrew Dunstan wrote: > > The DBI manpage says this: > > connect_cached is like connect, except that the database handle returned is > also stored in a hash associated with the given parameters. If another call > is made to connect_cached with the same parameter values, then the > corresponding cached $dbh will be returned if it is still valid. The cached > database handle is replaced with a new connection if it has been > disconnected or if the ping method fails. > > Note that the behavior of this method differs in several respects from the > behavior of presistent (sic) connections implemented by Apache::DBI. > > What are the differences? Apache::DBI uses a cleanup handler to rollback any uncomitted transactions after each request. It is also transparent, i.e. you can use normal connect statements and turn the persistence on or off by putting in Apache::DBI or not. There are probably other differences that I'm not aware of. - Perrin
DBI connect_cached vs Apache::DBI
The DBI manpage says this: connect_cached is like connect, except that the database handle returned is also stored in a hash associated with the given parameters. If another call is made to connect_cached with the same parameter values, then the corresponding cached $dbh will be returned if it is still valid. The cached database handle is replaced with a new connection if it has been disconnected or if the ping method fails. Note that the behavior of this method differs in several respects from the behavior of presistent (sic) connections implemented by Apache::DBI. What are the differences? cheers andrew
Re: Apache::DBI strategy/philosophy
John M Vinopal wrote: > For programmer ease you probally want to connect inside a module, and for > mod_perl speed you want to preload that module. But you can't do both AND > connect once at the start. Mod_perl insists that dbh connections must not > be made in the parent and then used in the child: that means that you cannot > initialize your dbh in BEGIN or outside of a subroutine. You can preload the module without actually making the connection. When using Apache::DBI, you do want to call DBI->connect once per request so that your database handle will be ping'ed. You can use Apache::DBI->connect_on_init() to make sure that there's a cached connection waiting for you when you issue your first DBI->connect(). - Perrin
Re: Apache::DBI strategy/philosophy
Part of the problem I've had is transitioning a cgi application onto mod_perl and keeping performance up on both platforms until a switch can be made. So I've done some comparisons of the various dbh schemes. Comments and corrections very welcome. I'm wary of connect_cached() under mod_perl but perhaps for no good reason. DBI Connection Tests Since connecting can be expensive, you generally just connect at the start of your program and disconnect at the end. DBI.pm 1.14 docs For programmer ease you probally want to connect inside a module, and for mod_perl speed you want to preload that module. But you can't do both AND connect once at the start. Mod_perl insists that dbh connections must not be made in the parent and then used in the child: that means that you cannot initialize your dbh in BEGIN or outside of a subroutine. The trickier problem involves a popular hack '$dbh ||= connect()', in CGI this will work effectively, however in mod_perl the variable $dbh is persistent between invocations. Should your database vanish, the connection within $dbh will be invalid, but the variable $dbh will still be a TRUE value and all of your queries will fail until you restart apache (ie: ||= doesn't call ping()). This benchmark compares some different techiques of DBI connection and discusses their merits. Each set of DBI connections is done inside a module. Each module calls a number of subroutines, all of which perform database operations. There are 14 connect and execute calls over two different database handles. Run from the command line Benchmark: timing 20 iterations of 0 my, 1 local, 2 or, 3 global, 4 cache, 5 cache my... 0 my: 55 wallclock secs ( 5.47 usr 3.44 sys + 22.36 cusr 21.31 csys = 52.58 CPU) @ 2.24/s (n=20) 1 local: 52 wallclock secs ( 5.54 usr 3.48 sys + 20.86 cusr 19.99 csys = 49.87 CPU) @ 2.22/s (n=20) 2 or: 12 wallclock secs ( 2.13 usr 0.74 sys + 2.58 cusr 3.08 csys = 8.53 CPU) @ 6.97/s (n=20) 3 global: 12 wallclock secs ( 2.11 usr 0.84 sys + 2.60 cusr 3.04 csys = 8.59 CPU) @ 6.78/s (n=20) 4 cache: 13 wallclock secs ( 2.80 usr 0.91 sys + 2.73 cusr 2.94 csys = 9.38 CPU) @ 5.39/s (n=20) 5 cache my: 13 wallclock secs ( 2.82 usr 0.89 sys + 2.87 cusr 2.77 csys = 9.35 CPU) @ 5.39/s (n=20) Run under CGI Benchmark: timing 20 iterations of 0 my, 1 local, 2 or, 3 global, 4 cache, 5 cache my... 0 my: 54 wallclock secs ( 5.31 usr 2.90 sys + 22.34 cusr 21.20 csys = 51.75 CPU) @ 2.44/s (n=20) 1 local: 51 wallclock secs ( 5.49 usr 2.88 sys + 20.78 cusr 19.96 csys = 49.11 CPU) @ 2.39/s (n=20) 2 or: 12 wallclock secs ( 2.35 usr 0.63 sys + 2.74 cusr 2.82 csys = 8.54 CPU) @ 6.71/s (n=20) 3 global: 12 wallclock secs ( 2.28 usr 0.68 sys + 2.59 cusr 2.86 csys = 8.41 CPU) @ 6.76/s (n=20) 4 cache: 13 wallclock secs ( 2.88 usr 0.76 sys + 2.82 cusr 2.86 csys = 9.32 CPU) @ 5.49/s (n=20) 5 cache my: 13 wallclock secs ( 2.99 usr 0.67 sys + 2.84 cusr 2.77 csys = 9.27 CPU) @ 5.46/s (n=20) Run under Apache::PerlRun and NO Apache::DBI Benchmark: timing 20 iterations of 0 my, 1 local, 2 or, 3 global, 4 cache, 5 cache my... 0 my: 55 wallclock secs ( 5.43 usr 3.23 sys + 21.99 cusr 22.04 csys = 52.69 CPU) @ 2.31/s (n=20) 1 local: 53 wallclock secs ( 5.49 usr 3.35 sys + 21.34 cusr 19.83 csys = 50.01 CPU) @ 2.26/s (n=20) 2 or: 12 wallclock secs ( 2.12 usr 0.67 sys + 2.85 cusr 2.82 csys = 8.46 CPU) @ 7.17/s (n=20) 3 global: 12 wallclock secs ( 2.12 usr 0.74 sys + 2.69 cusr 2.88 csys = 8.43 CPU) @ 6.99/s (n=20) 4 cache: 13 wallclock secs ( 2.89 usr 0.80 sys + 2.67 cusr 2.93 csys = 9.29 CPU) @ 5.42/s (n=20) 5 cache my: 12 wallclock secs ( 3.08 usr 0.72 sys + 2.61 cusr 2.86 csys = 9.27 CPU) @ 5.26/s (n=20) Run under Apache::PerlRun and Apache::DBI Benchmark: timing 20 iterations of 0 my, 1 local, 2 or, 3 global, 4 cache, 5 cache my... 0 my: 12 wallclock secs ( 2.29 usr 0.58 sys + 2.64 cusr 2.82 csys = 8.33 CPU) @ 6.97/s (n=20) 1 local: 12 wallclock secs ( 2.43 usr 0.61 sys + 2.61 cusr 3.02 csys = 8.67 CPU) @ 6.58/s (n=20) 2 or: 11 wallclock secs ( 2.14 usr 0.69 sys + 2.98 cusr 2.95 csys = 8.76 CPU) @ 7.07/s (n=20) 3 global: 12 wallclock secs ( 2.16 usr 0.66 sys + 2.61 cusr 2.86 csys = 8.29 CPU) @ 7.09/s (n=20) 4 cache: 12 wallclock secs ( 2.72 usr 0.74 sys + 2.80 cusr 2.81 csys = 9.07 CPU) @ 5.78/s (n=20) 5 cache my: 13 wallclock secs ( 2.97 usr 0.76 sys + 2.79 cusr 2.88 csys = 9.40 CPU) @ 5.36/s (n=20) EXPLANATION OF THE TESTS my: my dbh are created within the subroutines. CGI: slow due to reconnections. MOD_PERL: safe for preloading. local: Global dbh are initialized within the subroutines. CGI: slow due to reconnections. MOD_PERL: safe for preloading. or: Global dbh are initialized if false using ||= CGI: fast due to single
Re: Apache::DBI broken?
>>>>> "Perrin" == Perrin Harkins <[EMAIL PROTECTED]> writes: Perrin> Make sure you're loading it before DBI, including any scripts that use Perrin> DBI. Try putting "PerlModule Apache::DBI" right up at the top of your Perrin> httpd.conf and see if that fixes things. I'm hoping that some future version of Apache::DBI eliminates this requirement, as it doesn't survive a reload very well. This has been discussed on this mailing list before. Maybe someone could provide the patch finally, so it gets done. I'm not asking for an existing DBI handle to be cached, but any new DBI handles should come from a pool once Apache::DBI has been seen. -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 <[EMAIL PROTECTED]> http://www.stonehenge.com/merlyn/> Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
RE: Apache::DBI broken?
It was PHP4. A rebuild fixed it. Thanks guys!
> -Original Message-
> From: Ian Mahuron [mailto:[EMAIL PROTECTED]]
> Sent: Friday, June 16, 2000 01:50 PM
> To: Edmund Mergl
> Cc: Mailing List, mod_perl
> Subject: RE: Apache::DBI broken?
>
>
>
> Everything except MySQL was built up from sources (no ports). All modules
> are linked static.
>
> As per your advice, I nixed the load of Apache::DBI... and it still
> segfaults.. so the problem obviously lies w/ DBI or the DBD for mysql.
> Having read more of the mod_perl list archives, it seems that
> there may be a
> bug in the mysql driver (see "Segfault on DBI->Connect (04/01/2000)"
> thread).
>
> Considering how recently (and frequently) this has poped up on the list, I
> wonder if Indrek is right.. Is php4 the culprit?
>
> Ian
>
> > -Original Message-
> > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of
> > Edmund Mergl
> > Sent: Friday, June 16, 2000 01:31 PM
> > To: Ian Mahuron
> > Cc: Mailing List, mod_perl
> > Subject: Re: Apache::DBI broken?
> >
> >
> > Ian Mahuron wrote:
> > >
> > > I've been searching through the mailing list and have seen
> > several people
> > > with the same problem I'm experiencing. Yet I've seen no solid
> > answers to
> > > this problem... so maybe I'll try again.
> > >
> > > System is:
> > > FreeBSD 4.0
> > > Apache 1.3.12
> > > perl 5.005_03
> > > mod_perl 1.24
> > > DBI 1.14
> > > Apache::DBI 0.87
> > >
> > > # Apache::DBI preloaded via:
> > > use Apache::DBI; # in startup.pl
> > >
> > > # DB handles created via:
> > > my $dbh = DBI->connect('...');
> > >
> > > Every module that contains DBI->connect causes the server to segfault:
> > > [Fri Jun 16 12:05:41 2000] [notice] child pid 41672 exit signal
> > Segmentation
> > > fault (11)
> > >
> > > I wrote up a quick script in perl to test DBI and it works fine.
> > >
> > > If any other information is required, please let me know.
> >
> >
> > in order to check whether Apache::DBI makes the trouble, just remove
> > the 'use Apache::DBI;' from startup.pl and check if the problem
> > disappears.
> >
> > Do you use statically linked mod_perl or is mod_perl a DSO ?
> >
> > Edmund
> >
> >
> > --
> > Edmund Mergl
> > mailto:[EMAIL PROTECTED]
> > http://www.edmund-mergl.de
> > fon: +49 700 EDEMERGL
> >
>
>
RE: Apache::DBI broken?
Everything except MySQL was built up from sources (no ports). All modules
are linked static.
As per your advice, I nixed the load of Apache::DBI... and it still
segfaults.. so the problem obviously lies w/ DBI or the DBD for mysql.
Having read more of the mod_perl list archives, it seems that there may be a
bug in the mysql driver (see "Segfault on DBI->Connect (04/01/2000)"
thread).
Considering how recently (and frequently) this has poped up on the list, I
wonder if Indrek is right.. Is php4 the culprit?
Ian
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of
> Edmund Mergl
> Sent: Friday, June 16, 2000 01:31 PM
> To: Ian Mahuron
> Cc: Mailing List, mod_perl
> Subject: Re: Apache::DBI broken?
>
>
> Ian Mahuron wrote:
> >
> > I've been searching through the mailing list and have seen
> several people
> > with the same problem I'm experiencing. Yet I've seen no solid
> answers to
> > this problem... so maybe I'll try again.
> >
> > System is:
> > FreeBSD 4.0
> > Apache 1.3.12
> > perl 5.005_03
> > mod_perl 1.24
> > DBI 1.14
> > Apache::DBI 0.87
> >
> > # Apache::DBI preloaded via:
> > use Apache::DBI; # in startup.pl
> >
> > # DB handles created via:
> > my $dbh = DBI->connect('...');
> >
> > Every module that contains DBI->connect causes the server to segfault:
> > [Fri Jun 16 12:05:41 2000] [notice] child pid 41672 exit signal
> Segmentation
> > fault (11)
> >
> > I wrote up a quick script in perl to test DBI and it works fine.
> >
> > If any other information is required, please let me know.
>
>
> in order to check whether Apache::DBI makes the trouble, just remove
> the 'use Apache::DBI;' from startup.pl and check if the problem
> disappears.
>
> Do you use statically linked mod_perl or is mod_perl a DSO ?
>
> Edmund
>
>
> --
> Edmund Mergl
> mailto:[EMAIL PROTECTED]
> http://www.edmund-mergl.de
> fon: +49 700 EDEMERGL
>
RE: Apache::DBI broken?
> "IM" == Ian Mahuron <[EMAIL PROTECTED]> writes: IM> php4 *is* in the mix! I installed it just so we could use phpMyAdmin (neat IM> MySQL web client). Can you ellaborate on this (URL, docs, etc)?? Is there IM> a patch for php4 or should I jump back to php3? by default, when you build php4 with mysql, it compiles its own copy of the mysql client library statically into itself. you need to tell it explicitly to use your pre-installed copy. if this is a shared lib, it will be more friendly to the DBI since they will not have any conflicting name space issues.
RE: Apache::DBI broken?
Hi, > php4 *is* in the mix! I installed it just so we could use > phpMyAdmin (neat MySQL web client). Can you ellaborate on this > (URL, docs, etc)?? Is there a patch for php4 or should I jump > back to php3? you just need to compile PHP4 with --with-mysql=/path/to/your/mysql. if you use just --with-mysql, the internal mysql minilib will be used. Rgds, Tfr --==< [EMAIL PROTECTED] >==< MySQL development team >==< Thibodaux, LA / USA >==--
RE: Apache::DBI broken?
php4 *is* in the mix! I installed it just so we could use phpMyAdmin (neat MySQL web client). Can you ellaborate on this (URL, docs, etc)?? Is there a patch for php4 or should I jump back to php3? Thanks! Ian > -Original Message- > From: indrek siitan [mailto:[EMAIL PROTECTED]] > Sent: Friday, June 16, 2000 01:17 PM > To: Ian Mahuron; [EMAIL PROTECTED] > Subject: RE: Apache::DBI broken? > > > Hi, > > > System is: > > FreeBSD 4.0 > > Apache 1.3.12 > > perl 5.005_03 > > mod_perl 1.24 > > DBI 1.14 > > Apache::DBI 0.87 > > are you sure you don't have PHP4 in this mix? if you have compiled > PHP4 with its internal support for MySQL, it will conflict with > mod_perl. > > > Rgds, > Tfr > > --==< [EMAIL PROTECTED] >==< MySQL development team >==< Thibodaux, > LA / USA >==-- >
RE: Apache::DBI broken?
Hi, > System is: > FreeBSD 4.0 > Apache 1.3.12 > perl 5.005_03 > mod_perl 1.24 > DBI 1.14 > Apache::DBI 0.87 are you sure you don't have PHP4 in this mix? if you have compiled PHP4 with its internal support for MySQL, it will conflict with mod_perl. Rgds, Tfr --==< [EMAIL PROTECTED] >==< MySQL development team >==< Thibodaux, LA / USA >==--
Re: Apache::DBI broken?
Ian Mahuron wrote:
>
> I've been searching through the mailing list and have seen several people
> with the same problem I'm experiencing. Yet I've seen no solid answers to
> this problem... so maybe I'll try again.
>
> System is:
> FreeBSD 4.0
> Apache 1.3.12
> perl 5.005_03
> mod_perl 1.24
> DBI 1.14
> Apache::DBI 0.87
>
> # Apache::DBI preloaded via:
> use Apache::DBI; # in startup.pl
>
> # DB handles created via:
> my $dbh = DBI->connect('...');
>
> Every module that contains DBI->connect causes the server to segfault:
> [Fri Jun 16 12:05:41 2000] [notice] child pid 41672 exit signal Segmentation
> fault (11)
>
> I wrote up a quick script in perl to test DBI and it works fine.
>
> If any other information is required, please let me know.
in order to check whether Apache::DBI makes the trouble, just remove
the 'use Apache::DBI;' from startup.pl and check if the problem
disappears.
Do you use statically linked mod_perl or is mod_perl a DSO ?
Edmund
--
Edmund Mergl
mailto:[EMAIL PROTECTED]
http://www.edmund-mergl.de
fon: +49 700 EDEMERGL
Re: Apache::DBI broken?
I had similar problems. In startup.pl, where you are calling
'use Apache::DBI;', do you call 'use DBI;' following the call to
Apache::DBI ? When I included that in startup.pl.. it started
behaving better.. my $0.02 -Casey
On Fri, 16 Jun 2000, Ian Mahuron wrote:
>
> I've been searching through the mailing list and have seen several people
> with the same problem I'm experiencing. Yet I've seen no solid answers to
> this problem... so maybe I'll try again.
>
> System is:
> FreeBSD 4.0
> Apache 1.3.12
> perl 5.005_03
> mod_perl 1.24
> DBI 1.14
> Apache::DBI 0.87
>
> # Apache::DBI preloaded via:
> use Apache::DBI; # in startup.pl
>
> # DB handles created via:
> my $dbh = DBI->connect('...');
>
> Every module that contains DBI->connect causes the server to segfault:
> [Fri Jun 16 12:05:41 2000] [notice] child pid 41672 exit signal Segmentation
> fault (11)
>
> I wrote up a quick script in perl to test DBI and it works fine.
>
> If any other information is required, please let me know.
>
>
--
-Casey
Re: Apache::DBI broken?
Make sure you're loading it before DBI, including any scripts that use
DBI. Try putting "PerlModule Apache::DBI" right up at the top of your
httpd.conf and see if that fixes things.
- Perrin
On Fri, 16 Jun 2000, Ian Mahuron wrote:
>
> I've been searching through the mailing list and have seen several people
> with the same problem I'm experiencing. Yet I've seen no solid answers to
> this problem... so maybe I'll try again.
>
> System is:
> FreeBSD 4.0
> Apache 1.3.12
> perl 5.005_03
> mod_perl 1.24
> DBI 1.14
> Apache::DBI 0.87
>
> # Apache::DBI preloaded via:
> use Apache::DBI; # in startup.pl
>
> # DB handles created via:
> my $dbh = DBI->connect('...');
>
> Every module that contains DBI->connect causes the server to segfault:
> [Fri Jun 16 12:05:41 2000] [notice] child pid 41672 exit signal Segmentation
> fault (11)
>
> I wrote up a quick script in perl to test DBI and it works fine.
>
> If any other information is required, please let me know.
>
Apache::DBI broken?
I've been searching through the mailing list and have seen several people
with the same problem I'm experiencing. Yet I've seen no solid answers to
this problem... so maybe I'll try again.
System is:
FreeBSD 4.0
Apache 1.3.12
perl 5.005_03
mod_perl 1.24
DBI 1.14
Apache::DBI 0.87
# Apache::DBI preloaded via:
use Apache::DBI; # in startup.pl
# DB handles created via:
my $dbh = DBI->connect('...');
Every module that contains DBI->connect causes the server to segfault:
[Fri Jun 16 12:05:41 2000] [notice] child pid 41672 exit signal Segmentation
fault (11)
I wrote up a quick script in perl to test DBI and it works fine.
If any other information is required, please let me know.
Re: Apache::DBI strategy/philosophy
Tim Gardner wrote: > > I have been using DBI without Apache::DBI and have been simply > storing db connections in a global variable as a sort of poor man's > persistent connection when running under Apache::Registry. > > Now I want to do things "right" and am trying to understand > Apache::DBI. Before looking at the module I imagined that it would > work by providing a library of persistent connections. You would > check a connnection out of the library, use it, and then put it back > when you are done, like checking a book out of the library. If you > disconnected the connection, you just wouldn't return it, and the > pool would have to create a new connection for the next user. > > But this is not the way Apache::DBI works. Instead, if I understand > correctly after glancing at the module this morning, two consecutive > identical connect calls will return the same connection! Why isn't > this a problem? Is the assumption that two different transactions > will use different user/pwd combinations? > > Thanks, > Tim Apache (version 1.x) uses a multi-process approach for serving as many requests as possible in parallel. Every httpd process has its own address space. A database connection opened by one specific httpd can not be shared with another httpd. At most you will get a segmentation violation. Hence every httpd needs to keep its own pool of persistent database connections. As a direct consequence it is not possible to use more than one HTTP request inside one transaction, because you can not control which httpd will server a specific request. Very likely two requests will be served by two different httpds where both do not know anything about a common transaction. Edmund -- Edmund Mergl mailto:[EMAIL PROTECTED] http://www.edmund-mergl.de fon: +49 700 EDEMERGL
Re: Apache::DBI strategy/philosophy
Tim wrote: > Now I want to do things "right" and am trying to understand > Apache::DBI. Before looking at the module I imagined that it would > work by providing a library of persistent connections. You would > check a connnection out of the library, use it, and then put it back > when you are done, like checking a book out of the library. If you > disconnected the connection, you just wouldn't return it, and the > pool would have to create a new connection for the next user. Hrrmm. In this case though how would you discern between a slow connection and a 'disconnect' on the clients side ?! As far as we are aware, you couldnt, unless you sent back some sort of message to the server in which case it may as well deal with the disconnection itself at that point. (jst our opinion ;) > But this is not the way Apache::DBI works. Instead, if I understand > correctly after glancing at the module this morning, two consecutive > identical connect calls will return the same connection! Why isn't > this a problem? Is the assumption that two different transactions > will use different user/pwd combinations? Afaik (or afaict) apache::dbi seems to cache any connection by l&p (login and passwd) and server host/dbname. This is fine for us here because everyone has a unique l&p to the database anywayz. If you only use one for l&p for all connections, then it doesnt really matter 'who has the handle' as long as its open for business surely ?! The dbi handle (in other words) doesnt block whilst in a cgi, which you seem to think it is doing. It _will_ (if i read this right) if you have a large select or fetchrow call, but otherwise the concurrency shouldnt really be a problem (its all a matter how of how quick/slow your queries are). personally, in our application here, the individuals do a lot of large transactions, and even though DBI might queue them up, it would cause unacceptable delays in processing time. of course, there are other things to worry about if everyone has a unique l&p and more than once we have seen people advocating against this. your mileage may vary. > Thanks np (if i am right ;) ^stefs^
Apache::DBI strategy/philosophy
I have been using DBI without Apache::DBI and have been simply storing db connections in a global variable as a sort of poor man's persistent connection when running under Apache::Registry. Now I want to do things "right" and am trying to understand Apache::DBI. Before looking at the module I imagined that it would work by providing a library of persistent connections. You would check a connnection out of the library, use it, and then put it back when you are done, like checking a book out of the library. If you disconnected the connection, you just wouldn't return it, and the pool would have to create a new connection for the next user. But this is not the way Apache::DBI works. Instead, if I understand correctly after glancing at the module this morning, two consecutive identical connect calls will return the same connection! Why isn't this a problem? Is the assumption that two different transactions will use different user/pwd combinations? Thanks, Tim
Re: Modperl Test Problem and Redhat6.2 Apache::DBI strange thing. Thanks.
Steven Zhu wrote: > > Thank you for your quick answer. Is any way to find the thread about this > issue quickly? > I got most recent modperl and apache. I did all as you said as root. But test > is always problem. I has another machine. The machine has no problem for any > version > modperl and apache at all, always pass test. I guess that we missed something. > But it does not make sense because this professional OS redhat6.2 is > preinstalled on machine, should include all necessary libraries... I have no > idea, compiler does not > complain any thing, even no warnings or errors... I'd try searching for "test fail" and possibly "MacEachern" since Doug was the one who answered the question. The mailing list archives are listed on http://perl.apache.org/ > For redhat modperl rpm installation, i did not put PerlModule Apache::DBI > httpd.conf. Why i still can connect database(most time it is fine, but > sometimes > it is not fine.) because i put PerlModule Apache::DBI in httpd.conf. The web > server > does not startup. Any help would be appreciated. Thanks. My suggestion is to just forget the RPM version of modperl. You should always compile your own IMHO. I think others on this list would agree. The RPM that shipped with RH 6.1 (what about RH 6.2?) was very broken in several respects. -- Drew Taylor Vialogix Communications, Inc. 501 N. College Street Charlotte, NC 28202 704 370 0550 http://www.vialogix.com/
Re: Modperl Test Problem and Redhat6.2 Apache::DBI strange thing. Thanks.
Thank you for your quick answer. Is any way to find the thread about this issue quickly? I got most recent modperl and apache. I did all as you said as root. But test is always problem. I has another machine. The machine has no problem for any version modperl and apache at all, always pass test. I guess that we missed something. But it does not make sense because this professional OS redhat6.2 is preinstalled on machine, should include all necessary libraries... I have no idea, compiler does not complain any thing, even no warnings or errors... For redhat modperl rpm installation, i did not put PerlModule Apache::DBI httpd.conf. Why i still can connect database(most time it is fine, but sometimes it is not fine.) because i put PerlModule Apache::DBI in httpd.conf. The web server does not startup. Any help would be appreciated. Thanks. Steven. Drew Taylor wrote: > Steven Zhu wrote: > > > > Hi All: > > > > Thank you all for taking time to read this message. > > > > I got two things that i really don't understand. > > > > 1. I got RedHat6.2. I tried to install modperl. Apache1.3.12 and modperl > > 1.24. > > I installed every prerequired package. Configuration is fine and > > compiling is fine > > without any errors. But i never got test passed. The error messages: > > > > httpd listening on port 8529 > > will write error_log to: t/logs/error_log > > letting apache warm up...\c > > done > > /usr/bin/perl t/TEST 0 > > still waiting for server to warm up...not ok > > server failed to start! (please examine t/logs/error_log) at t/TEST line > > 95. > > make: *** [run_tests] Error 9 > > > > I check error.log file: > > > > [notice] Destruction->DESTROY called for $global_object > > [Tue Jun 13 18:42:39 2000] [warn] [notice] child_init for process 20497, > > report > > any problems to [no address given] > > > > There is nothing i can do. I am so frustrated because we has another > > machine upgrated from > > redhat5.2 to 6.1. We installed modperl without any problem. We tested > > everything ok. > > Please point out. Greate Thanks. > I remember a recent thread about this in the list. Try searching the > archives. You might also try running make test as root, rather than a > normal user. I could be wrong, but the right answer was given by > Doug(?). > > > 2. Since i can't get my new modperl running. I just use modperl coming > > with redhat6.2. > > The weired thing is that if i put PerlModule Apache::DBI in httpd.conf, > > the web server > > can not startup. If i take that out, the server can connect with > > database ( because i put > > use DBI; in perl script file?). But i can't get persistent connections, > > sometimes it can connect > > with database (mysql), sometimes it can't connect database with the > > following errors > I noticed this problem with Apache::DBI with the redhat mod_perl RPM. It > would just silently die, with no visible errors. > > The first thing to do is pull the latest Apache and mod_perl source > distributions (1.3.12 & 1.24) and compile it yourself. See the guide for > instructions - go ahead and use the "10 minutes to mod_perl" > instructions. > > -- > Drew Taylor > Vialogix Communications, Inc. > 501 N. College Street > Charlotte, NC 28202 > 704 370 0550 > http://www.vialogix.com/
Re: Modperl Test Problem and Redhat6.2 Apache::DBI strange thing. Thanks.
Steven Zhu wrote: > > Hi All: > > Thank you all for taking time to read this message. > > I got two things that i really don't understand. > > 1. I got RedHat6.2. I tried to install modperl. Apache1.3.12 and modperl > 1.24. > I installed every prerequired package. Configuration is fine and > compiling is fine > without any errors. But i never got test passed. The error messages: > > httpd listening on port 8529 > will write error_log to: t/logs/error_log > letting apache warm up...\c > done > /usr/bin/perl t/TEST 0 > still waiting for server to warm up...not ok > server failed to start! (please examine t/logs/error_log) at t/TEST line > 95. > make: *** [run_tests] Error 9 > > I check error.log file: > > [notice] Destruction->DESTROY called for $global_object > [Tue Jun 13 18:42:39 2000] [warn] [notice] child_init for process 20497, > report > any problems to [no address given] > > There is nothing i can do. I am so frustrated because we has another > machine upgrated from > redhat5.2 to 6.1. We installed modperl without any problem. We tested > everything ok. > Please point out. Greate Thanks. I remember a recent thread about this in the list. Try searching the archives. You might also try running make test as root, rather than a normal user. I could be wrong, but the right answer was given by Doug(?). > 2. Since i can't get my new modperl running. I just use modperl coming > with redhat6.2. > The weired thing is that if i put PerlModule Apache::DBI in httpd.conf, > the web server > can not startup. If i take that out, the server can connect with > database ( because i put > use DBI; in perl script file?). But i can't get persistent connections, > sometimes it can connect > with database (mysql), sometimes it can't connect database with the > following errors I noticed this problem with Apache::DBI with the redhat mod_perl RPM. It would just silently die, with no visible errors. The first thing to do is pull the latest Apache and mod_perl source distributions (1.3.12 & 1.24) and compile it yourself. See the guide for instructions - go ahead and use the "10 minutes to mod_perl" instructions. -- Drew Taylor Vialogix Communications, Inc. 501 N. College Street Charlotte, NC 28202 704 370 0550 http://www.vialogix.com/
Modperl Test Problem and Redhat6.2 Apache::DBI strange thing. Thanks.
Hi All: Thank you all for taking time to read this message. I got two things that i really don't understand. 1. I got RedHat6.2. I tried to install modperl. Apache1.3.12 and modperl 1.24. I installed every prerequired package. Configuration is fine and compiling is fine without any errors. But i never got test passed. The error messages: httpd listening on port 8529 will write error_log to: t/logs/error_log letting apache warm up...\c done /usr/bin/perl t/TEST 0 still waiting for server to warm up...not ok server failed to start! (please examine t/logs/error_log) at t/TEST line 95. make: *** [run_tests] Error 9 I check error.log file: [notice] Destruction->DESTROY called for $global_object [Tue Jun 13 18:42:39 2000] [warn] [notice] child_init for process 20497, report any problems to [no address given] There is nothing i can do. I am so frustrated because we has another machine upgrated from redhat5.2 to 6.1. We installed modperl without any problem. We tested everything ok. Please point out. Greate Thanks. 2. Since i can't get my new modperl running. I just use modperl coming with redhat6.2. The weired thing is that if i put PerlModule Apache::DBI in httpd.conf, the web server can not startup. If i take that out, the server can connect with database ( because i put use DBI; in perl script file?). But i can't get persistent connections, sometimes it can connect with database (mysql), sometimes it can't connect database with the following errors DBD::mysql::st execute failed: MySQL server has gone away at cnznetmod.pm line 1 59. DBD::mysql::st fetchrow failed: fetch() without execute() at cnznetmod.pm line 1 60. DBD::mysql::db do failed: MySQL server has gone away at cnznetmod.pm line 151. DBD::mysql::st execute failed: MySQL server has gone away at cnznetmod.pm line 1 59. DBD::mysql::st fetchrow failed: fetch() without execute() at cnznetmod.pm line 1 60. DBD::mysql::st execute failed: MySQL server has gone away at cnznetmod.pm line 1 30. DBD::mysql::st fetchrow failed: fetch() without execute() at cnznetmod.pm line 1 31. But it works in most time. I can't turn on debug because i can't put PerlModule Apache::DBI in httpd.conf. Thank you very much... Steven.
Re: Problems with Apache::DBI
Matt Carothers wrote:
>
> On Mon, 12 Jun 2000, Rob Tanner wrote:
>
> > Believe it or not, it's the simplest task in the world. In startup.pl add
> > the line "PerlModule Apache::DBI"
>
> You can either stick "PerlModule Apache::DBI" in your httpd.conf or add
> 'use Apache::DBI ();' to your startup.pl. Also, for mysql, you'll need
> to add a keepalive routine to your startup.pl:
>
> sub Apache::DBI::db::ping {
> my $dbh = shift;
> return $dbh->do('select 1');
> }
>
> - Matt
this is safer:
sub Apache::DBI::db::ping {
my $dbh = shift;
my $ret = 0;
eval {
local $SIG{__DIE__} = sub { return (0); };
local $SIG{__WARN__} = sub { return (0); };
$ret = $dbh->do('select 1');
};
return ($@) ? 0 : $ret;
}
Edmund
--
Edmund Mergl
mailto:[EMAIL PROTECTED]
http://www.edmund-mergl.de
fon: +49 700 EDEMERGL
Re: Problems with Apache::DBI
On Mon, 12 Jun 2000, Rob Tanner wrote:
> Believe it or not, it's the simplest task in the world. In startup.pl add
> the line "PerlModule Apache::DBI"
You can either stick "PerlModule Apache::DBI" in your httpd.conf or add
'use Apache::DBI ();' to your startup.pl. Also, for mysql, you'll need
to add a keepalive routine to your startup.pl:
sub Apache::DBI::db::ping {
my $dbh = shift;
return $dbh->do('select 1');
}
- Matt
Re: Problems with Apache::DBI
One other thing: Make sure the 'use Apache::DBI' comes before 'use DBI' in your startup.pl or httpd.conf file. Very important little step. :-) Other than that, it's a 5 minute drop in that works wonderfully! Rob Tanner wrote: > > Believe it or not, it's the simplest task in the world. In startup.pl add > the line "PerlModule Apache::DBI" I'm not sure how it does it's magic, but > basically, with that module loaded, DBI connection open/close requests go > through it and it maintains a persistant connection for you (the close is > replaced with a null, etc, so you don't even have to modify your banner > module. If you've installed Apache::DBI, simply grab the manpage, but > basically, all you do is add it to startup.pl. Neat, ain't it!! :-) -- Drew Taylor Vialogix Communications, Inc. 501 N. College Street Charlotte, NC 28202 704 370 0550 http://www.vialogix.com/
RE: Problems with Apache::DBI
>From what I read about the module, it overrides connect() and checks if the
connection has already been made. Overrides disconnect to not actually
disconnect. Pretty darn nifty.
--John
-Original Message-
From: Rob Tanner [mailto:[EMAIL PROTECTED]]
Sent: Monday, June 12, 2000 10:53 AM
To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: Re: Problems with Apache::DBI
Believe it or not, it's the simplest task in the world. In startup.pl add
the line "PerlModule Apache::DBI" I'm not sure how it does it's magic, but
basically, with that module loaded, DBI connection open/close requests go
through it and it maintains a persistant connection for you (the close is
replaced with a null, etc, so you don't even have to modify your banner
module. If you've installed Apache::DBI, simply grab the manpage, but
basically, all you do is add it to startup.pl. Neat, ain't it!! :-)
-- Rob
--On Monday, June 12, 2000 12:14 PM + [EMAIL PROTECTED] wrote:
> Hello,
> This message is urgent and could save our banner exchange.
> Recently we started growing so fast that we had to convert our entire
> system at Traffic-Exchange.com to mysql. Now that this is done we need
> persistant database connections to the mysql server. From downloading
> the Apache::DBI module I have no idea how to set this up.
>
> But what I can tell you is that we connect to the mysql database 1 time
> for every banner that is called by having this in our perl script:
> use DBI;
> $dbh =
> DBI->connect("dbi:mysql:$mysqldatabase","$mysqlusername","$mysqlpassword"
> ) || die("Couldn't connect to database!\n");
> &updatedatabase;
> $dbh->disconnect;
>
> Each time a banner is called that code is execuited meaning the database
> would open over 1,000 in a few min.
>
> From seeng this how is it that I can change this to use your module for
> persistant connections and what is it I need to do.
>
> The README was a bit confusing.
_ _ _ _ __ _ _ _ _
/\_\_\_\_\/\_\ /\_\_\_\_\_\
/\/_/_/_/_/ /\/_/ \/_/_/_/_/_/ QUIDQUID LATINE DICTUM SIT,
/\/_/__\/_/ __/\/_//\/_/ PROFUNDUM VIDITUR
/\/_/_/_/_/ /\_\ /\/_//\/_/
/\/_/ \/_/ /\/_/_/\/_//\/_/ (Whatever is said in Latin
\/_/ \/_/ \/_/_/_/_/ \/_/ appears profound)
Rob Tanner
McMinnville, Oregon
[EMAIL PROTECTED]
Re: Problems with Apache::DBI
Believe it or not, it's the simplest task in the world. In startup.pl add
the line "PerlModule Apache::DBI" I'm not sure how it does it's magic, but
basically, with that module loaded, DBI connection open/close requests go
through it and it maintains a persistant connection for you (the close is
replaced with a null, etc, so you don't even have to modify your banner
module. If you've installed Apache::DBI, simply grab the manpage, but
basically, all you do is add it to startup.pl. Neat, ain't it!! :-)
-- Rob
--On Monday, June 12, 2000 12:14 PM + [EMAIL PROTECTED] wrote:
> Hello,
> This message is urgent and could save our banner exchange.
> Recently we started growing so fast that we had to convert our entire
> system at Traffic-Exchange.com to mysql. Now that this is done we need
> persistant database connections to the mysql server. From downloading
> the Apache::DBI module I have no idea how to set this up.
>
> But what I can tell you is that we connect to the mysql database 1 time
> for every banner that is called by having this in our perl script:
> use DBI;
> $dbh =
> DBI->connect("dbi:mysql:$mysqldatabase","$mysqlusername","$mysqlpassword"
> ) || die("Couldn't connect to database!\n");
> &updatedatabase;
> $dbh->disconnect;
>
> Each time a banner is called that code is execuited meaning the database
> would open over 1,000 in a few min.
>
> From seeng this how is it that I can change this to use your module for
> persistant connections and what is it I need to do.
>
> The README was a bit confusing.
_ _ _ _ __ _ _ _ _
/\_\_\_\_\/\_\ /\_\_\_\_\_\
/\/_/_/_/_/ /\/_/ \/_/_/_/_/_/ QUIDQUID LATINE DICTUM SIT,
/\/_/__\/_/ __/\/_//\/_/ PROFUNDUM VIDITUR
/\/_/_/_/_/ /\_\ /\/_//\/_/
/\/_/ \/_/ /\/_/_/\/_//\/_/ (Whatever is said in Latin
\/_/ \/_/ \/_/_/_/_/ \/_/ appears profound)
Rob Tanner
McMinnville, Oregon
[EMAIL PROTECTED]
Problems with Apache::DBI
Hello,
This message is urgent and could save our banner exchange.
Recently we started growing so fast that we had to convert our entire system
at Traffic-Exchange.com to mysql. Now that this is done we need persistant
database connections to the mysql server. From downloading the Apache::DBI
module I have no idea how to set this up.
But what I can tell you is that we connect to the mysql database 1 time for
every banner that is called by having this in our perl script:
use DBI;
$dbh =
DBI->connect("dbi:mysql:$mysqldatabase","$mysqlusername","$mysqlpassword") ||
die("Couldn't connect to database!\n");
&updatedatabase;
$dbh->disconnect;
Each time a banner is called that code is execuited meaning the database
would open over 1,000 in a few min.
>From seeng this how is it that I can change this to use your module for
persistant connections and what is it I need to do.
The README was a bit confusing.
Re: Newbie: Apache::DBI Directive bug
Apache might barf on the PerlModule directive if you built modperl as a DSO, but forgot to actually include in httpd.conf LoadModule perl_module libexec/libperl.so Did you confirm that Apache has modperl loaded, perhaps with HEAD http://localhost/ John [EMAIL PROTECTED]
RE: Newbie: Apache::DBI Directive bug
> -Original Message- > From: Nigel Hamilton [mailto:[EMAIL PROTECTED]] > Sent: Thursday, May 25, 2000 3:40 AM > To: [EMAIL PROTECTED] > Subject: Newbie: Apache::DBI Directive bug > > > Hi, > I've got a showstopper bug ... > > Whenever I place the directive to load Apache::DBI in httpd.conf > I get a config file syntax error. can you be more specific about the contents of the error? Apache-DBI is not DBI, so you need to install both packages to get DBI to work... > > The directive is: PerlModule Apache::DBI > > I compiled mod_perl with EVERYTHING=1 ... can anyone tell me > why this would be the case? > > Thanks > > Nige > > p.s. also I've seen 'startup.pl' mentioned in FAQ's and in > the list ... > I'm interested in seeing an example startup.pl for DBI .. and how the > Apache server 'sources' this file at startup. look in the eg directory of the Apache-DBI installation for a startup.pl example... HTH --Geoff > > > >
Newbie: Apache::DBI Directive bug
Hi, I've got a showstopper bug ... Whenever I place the directive to load Apache::DBI in httpd.conf ... I get a config file syntax error. The directive is: PerlModule Apache::DBI I compiled mod_perl with EVERYTHING=1 ... can anyone tell me why this would be the case? Thanks Nige p.s. also I've seen 'startup.pl' mentioned in FAQ's and in the list ... I'm interested in seeing an example startup.pl for DBI .. and how the Apache server 'sources' this file at startup.
[Fwd: Apache::DBI, bug?]
Hi,
I installed Apache::DBI a while ago and it worked
fine then on Apache 1.3.12 using mod_perl 1.21.
Now I'm reinstalling apache still 1.3.12 with php4,
mod_perl 1.24, apache::dbi (most recent version) and the child processes of the
apache segfault on start. This happens as soon as I try to use PerlRequire in
httpd.conf.
The startup.pl file comes from
wwwthread.
The line the server segfaults in:
Apache::DBI->connect_on_init("DBI:$w3tvars::config{'dbdriver'}:$w3tvars::config{'dbname'}:$w3tvars::config{'dbserver'}",
"$w3tvars::config{'dbuser'}", "$w3tvars::config{'dbpass'}");
I've put the debug level to 2 and this is what I
get into the error_log:
[Tue May 23 17:36:40 2000] [notice] Apache/1.3.12
(Unix) mod_perl/1.24 PHP/4.0.0 configured -- resuming normal operations[Tue
May 23 17:36:40 2000] [info] Server built: May 23 2000 09:59:4120965
Apache::DBI
PerlChildInitHandler20966
Apache::DBI
PerlChildInitHandler20965
Apache::DBI
need ping: yes20966
Apache::DBI
need ping: yes20967
Apache::DBI
PerlChildInitHandler20969
Apache::DBI
PerlChildInitHandler20967
Apache::DBI
need ping: yes20969
Apache::DBI
need ping: yes20968
Apache::DBI
PerlChildInitHandler20968
Apache::DBI
need ping: yes[Tue May 23 17:36:41 2000] [notice] child pid 20969 exit
signal Segmentation fault (11)[Tue May 23 17:36:41 2000] [notice] child pid
20968 exit signal Segmentation fault (11)[Tue May 23 17:36:41 2000] [notice]
child pid 20967 exit signal Segmentation fault (11)[Tue May 23 17:36:41
2000] [notice] child pid 20966 exit signal Segmentation fault (11)[Tue May
23 17:36:41 2000] [notice] child pid 20965 exit signal Segmentation fault
(11)
It would be very nice if you could help me with
this one.
regards,
Gudmundur.
Re: Apache::DBI
On Mon, 22 May 2000, Mark Holt wrote: > Newbie to the list, apologies if this is a FAQ, but I checked the > archives... > I built a modperl-enabled server, (Apache/1.3.9 Ben-SSL/1.37 (Unix) > mod_perl/1.21) and have been running it for some time. I have the sounds like you need upgrade your mod_perl, dso fixes happened post-1.21
Re: Apache::DBI
> "EM" == Edmund Mergl <[EMAIL PROTECTED]> writes: >> mod_perl as a shared module, and I recently enabled it to start EM> EM> currently this does not work with DBI modules. EM> You have to re-build mod_perl + apache as a EM> statically linked binary. I disagree. mod_perl DSO works fine with DBI and DBD::mysql.
Re: Apache::DBI
Mark Holt wrote: > > Newbie to the list, apologies if this is a FAQ, but I checked the > archives... > I built a modperl-enabled server, (Apache/1.3.9 Ben-SSL/1.37 (Unix) > mod_perl/1.21) and have been running it for some time. I have the > mod_perl as a shared module, and I recently enabled it to start currently this does not work with DBI modules. You have to re-build mod_perl + apache as a statically linked binary. > development. I have a startup script in operation and things work fine, > until I try to preload any sort of DBI module. I tried Mysql, > DBI::mysql, Apache::DBI, all to no avail. The server gives no error > message, it simply acts as though it is starting, but does not show up > in the process list. Is there something I'm missing? > > Thanks in advance. Edmund -- Edmund Mergl mailto:[EMAIL PROTECTED] http://www.edmund-mergl.de fon: +49 700 EDEMERGL
Re: DBD::Oracle && Apache::DBI
We had some strange connection problems like this before. Our most common error was about the 'hostdef extension not found'.. We found that we could get around this by using fully qualified oracle database connection identifiers, instead of using the entry that appears in tnsnames.ora, for example: dbi:Oracle:web becomes something like this dbi:Oracle:(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=.. ))) It's worked like a champ since then... I'm not sure why it works, probably because I've removed a few layers of indirection.. Either that or some environment variable is getting corrupted.. On Mon, May 22, 2000 at 06:36:54PM -0700, Ian Kallen wrote: > > I've done everything I can think of to shore up any DB connection > flakiness but I'm still plagued by errors such as these: > DBD::Oracle::db selectcol_arrayref failed: ORA-12571: TNS:packet writer > failure > ...this is only a problem under mod_perl, outside of the > mod_perl/Apache::DBI environment everything seems fine. Once the db > connection is in this state, it's useless until the server gets a restart. > > My connect strings look good and agree, I put Stas' ping method in the > DBD::Oracle::db package, set a low timeout, called Oracle (they don't > want to hear about it). Everything is the latest versions of > mod_perl/Apache/DBI/DBD::Oracle connecting to an Oracle 8.1.5 db on > Solaris. Is Apache::DBI not up to it? (it looks simple enough) > > Maybe there's a better persistent connection method I should be looking > at? > > -- > Salon Internethttp://www.salon.com/ > Manager, Software and Systems "Livin' La Vida Unix!" > Ian Kallen <[EMAIL PROTECTED]> / AIM: iankallen / Fax: (415) 354-3326 -- Paul Lindner [EMAIL PROTECTED] Red Hat Inc. San Francisco, USA
RE: :Oracle && Apache::DBI
Ian-- I very occasionally get these errors while using DBI and DBD::Oracle under mod_perl. I find that it generally happens when a random, perfectly good SQL statement causes the Oracle process dump the connection and write the reason to alert.log. Try doing the following: from your oracle home, run: > find . -name 'alert*' -print Go to that directory, read the alert files, and look through any corresponding trace files. The trace files contain the sql that actually cause the trace dump. I find that I can usually rewrite the sql statement in such a way that it no longer dumps core. Again, this happens _very_ rarely. Hope this helps, Ed -Original Message- From: Ian Kallen [mailto:[EMAIL PROTECTED]] Sent: Monday, May 22, 2000 9:37 PM To: [EMAIL PROTECTED] Subject: DBD::Oracle && Apache::DBI I've done everything I can think of to shore up any DB connection flakiness but I'm still plagued by errors such as these: DBD::Oracle::db selectcol_arrayref failed: ORA-12571: TNS:packet writer failure ...this is only a problem under mod_perl, outside of the mod_perl/Apache::DBI environment everything seems fine. Once the db connection is in this state, it's useless until the server gets a restart. My connect strings look good and agree, I put Stas' ping method in the DBD::Oracle::db package, set a low timeout, called Oracle (they don't want to hear about it). Everything is the latest versions of mod_perl/Apache/DBI/DBD::Oracle connecting to an Oracle 8.1.5 db on Solaris. Is Apache::DBI not up to it? (it looks simple enough) Maybe there's a better persistent connection method I should be looking at? -- Salon Internet http://www.salon.com/ Manager, Software and Systems "Livin' La Vida Unix!" Ian Kallen <[EMAIL PROTECTED]> / AIM: iankallen / Fax: (415) 354-3326
Re: DBD::Oracle && Apache::DBI
Ian Kallen wrote: > > I've done everything I can think of to shore up any DB connection > flakiness but I'm still plagued by errors such as these: > DBD::Oracle::db selectcol_arrayref failed: ORA-12571: TNS:packet writer > failure > ...this is only a problem under mod_perl, outside of the > mod_perl/Apache::DBI environment everything seems fine. Once the db > connection is in this state, it's useless until the server gets a restart. > > My connect strings look good and agree, I put Stas' ping method in the > DBD::Oracle::db package, set a low timeout, called Oracle (they don't > want to hear about it). Everything is the latest versions of > mod_perl/Apache/DBI/DBD::Oracle connecting to an Oracle 8.1.5 db on > Solaris. Is Apache::DBI not up to it? (it looks simple enough) > > Maybe there's a better persistent connection method I should be looking > at? > > -- > Salon Internet http://www.salon.com/ > Manager, Software and Systems "Livin' La Vida Unix!" > Ian Kallen <[EMAIL PROTECTED]> / AIM: iankallen / Fax: (415) 354-3326 I don't think this has anything to do with mod_perl - as I have seen this error on my own development box using sqlplus on Linux with Oracle 8. It seems to happen when I use ^C to interrupt a previous request. Amy
Re: Apache::DBI
On Mon, 22 May 2000, Mark Holt wrote: > I have tried pulling in *any* DBI or DBD module one at a time and ALL > of them cause the server to fail to start. There is no error log > message. Does DBI work for you from command-line scripts? Did the tests for DBD::mysql pass? > Is there an order I must use them in? Apache::DBI installed without a > hitch, are there other pitfalls of which I should be aware? Yes, the Apache::DBI docs explain that you must load it before any other DBI-related modules. - Perrin
Re: Apache::DBI
I have tried pulling in *any* DBI or DBD module one at a time and ALL of them cause the server to fail to start. There is no error log message. This is true whether I use the PerlModule config directive, or 'use' the module in the script defined in the PerlScript directive. I have other modules in the script, and until the database module is used, it starts OK. Is there an order I must use them in? Apache::DBI installed without a hitch, are there other pitfalls of which I should be aware? Perrin Harkins wrote: > On Mon, 22 May 2000, Mark Holt wrote: > > > Newbie to the list, apologies if this is a FAQ, but I checked the > > archives... > > I built a modperl-enabled server, (Apache/1.3.9 Ben-SSL/1.37 (Unix) > > mod_perl/1.21) and have been running it for some time. I have the > > mod_perl as a shared module, and I recently enabled it to start > > development. I have a startup script in operation and things work fine, > > until I try to preload any sort of DBI module. I tried Mysql, > > DBI::mysql, Apache::DBI, all to no avail. The server gives no error > > message, it simply acts as though it is starting, but does not show up > > in the process list. Is there something I'm missing? > > Are you pulling in the DBI and DBD modules in your startup.pl? Is there > any message in the error_log? Apache::DBI is not at all like DBD::mysql, > so it sounds like you may have a problem totally unrelated to DBI. > > - Perrin
Re: DBD::Oracle && Apache::DBI
On Mon, 22 May 2000, Ian Kallen wrote: > I've done everything I can think of to shore up any DB connection > flakiness but I'm still plagued by errors such as these: > DBD::Oracle::db selectcol_arrayref failed: ORA-12571: TNS:packet writer > failure > ...this is only a problem under mod_perl, outside of the > mod_perl/Apache::DBI environment everything seems fine. Once the db > connection is in this state, it's useless until the server gets a restart. > > My connect strings look good and agree, I put Stas' ping method in the > DBD::Oracle::db package, set a low timeout, called Oracle (they don't > want to hear about it). Everything is the latest versions of > mod_perl/Apache/DBI/DBD::Oracle connecting to an Oracle 8.1.5 db on > Solaris. Is Apache::DBI not up to it? (it looks simple enough) > > Maybe there's a better persistent connection method I should be looking > at? Apache::DBI is dirt simple, and it's the only method I know for persistent connections. You can just keep your $dbh as a global, but Apache::DBI is just barely more complex than that. Your problem is almost certainly coming from Oracle in one way or another. You may not see this happening with non mod_perl scripts because they don't live long enough or peform enough queries. One thing I've encountered is that when the ping method fails in a child process I can never get a successful reconnect from that same process again. I get around this by killing that process (Apache::exit()) after it sends out an error page. New child processes spawned by Apache don't have any trouble connecting. This is with Oracle 8 on Linux. - Perrin
Re: DBD::Oracle && Apache::DBI
My guess is that the problem lies within DBD::Oracle or more likely within Oracle itself. If you can create a Perl only reproducible example, the dbi-users folks will help. John [EMAIL PROTECTED]
Re: Apache::DBI
On Mon, 22 May 2000, Mark Holt wrote: > Newbie to the list, apologies if this is a FAQ, but I checked the > archives... > I built a modperl-enabled server, (Apache/1.3.9 Ben-SSL/1.37 (Unix) > mod_perl/1.21) and have been running it for some time. I have the > mod_perl as a shared module, and I recently enabled it to start > development. I have a startup script in operation and things work fine, > until I try to preload any sort of DBI module. I tried Mysql, > DBI::mysql, Apache::DBI, all to no avail. The server gives no error > message, it simply acts as though it is starting, but does not show up > in the process list. Is there something I'm missing? Are you pulling in the DBI and DBD modules in your startup.pl? Is there any message in the error_log? Apache::DBI is not at all like DBD::mysql, so it sounds like you may have a problem totally unrelated to DBI. - Perrin
DBD::Oracle && Apache::DBI
I've done everything I can think of to shore up any DB connection flakiness but I'm still plagued by errors such as these: DBD::Oracle::db selectcol_arrayref failed: ORA-12571: TNS:packet writer failure ...this is only a problem under mod_perl, outside of the mod_perl/Apache::DBI environment everything seems fine. Once the db connection is in this state, it's useless until the server gets a restart. My connect strings look good and agree, I put Stas' ping method in the DBD::Oracle::db package, set a low timeout, called Oracle (they don't want to hear about it). Everything is the latest versions of mod_perl/Apache/DBI/DBD::Oracle connecting to an Oracle 8.1.5 db on Solaris. Is Apache::DBI not up to it? (it looks simple enough) Maybe there's a better persistent connection method I should be looking at? -- Salon Internet http://www.salon.com/ Manager, Software and Systems "Livin' La Vida Unix!" Ian Kallen <[EMAIL PROTECTED]> / AIM: iankallen / Fax: (415) 354-3326
Apache::DBI
Newbie to the list, apologies if this is a FAQ, but I checked the archives... I built a modperl-enabled server, (Apache/1.3.9 Ben-SSL/1.37 (Unix) mod_perl/1.21) and have been running it for some time. I have the mod_perl as a shared module, and I recently enabled it to start development. I have a startup script in operation and things work fine, until I try to preload any sort of DBI module. I tried Mysql, DBI::mysql, Apache::DBI, all to no avail. The server gives no error message, it simply acts as though it is starting, but does not show up in the process list. Is there something I'm missing? Thanks in advance.
Apache::DBI / Sybase driver DESTROY errors
One these start, they don't stop unless I restart the server. Any idea what is causing these? [Sat May 20 11:49:41 2000] [error] Undefined subroutine &DBD::Sybase::db::_login called at /usr/local/lib/perl5/site_perl/5.6.0/i686-linux/DBD/Sybase.pm line 73. (in cleanup) Driver has not implemented DESTROY for DBI::db=HASH(0x848fd88) at /usr/local/lib/perl5/site_perl/5.6.0/i686-linux/Apache/Registry.pm line 144 Thanks
Re: Q: DBMS update framework for use within Apache::DBI?
"Bruce W. Hoylman" wrote: > > > "Gunther" == Gunther Birznieks <[EMAIL PROTECTED]> writes: > Gunther> This first criteria seems a tad odd to me. What business > Gunther> scenario is there for this? > > The framework is to support an intranet time tracking application. The > business rules of the system dictate there are no deletions of > previously submitted time ... only inserts/updates. Therefore I can say > without question that an existing time record will *always* exist (a > modify), albeit in a potentially 'dirty' state (rule #2). > > Furthermore, if a particular time period has not been accounted for, > i.e. no time record has been previously submitted, a default time > record will be presented for modification, and subsequent submission (an > insert). This is seamless to the client requesting the period. If > there is no default time record available, then a 0-hour time record is > presented for modification/submission (also an insert). need custom record locking? how about adding a field such as 'lock' which is set when a record is requested, so only one user can modify it? i.e. your script sends a flag to others who've requested a 'lock'ed record. i'd also put a timeout on it so that if a user quits his browser or gets distracted, his page gets updated to another location after freeing up the lock... -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Their is five errers in this sentance.
Re: Confusion on Apache::DBI
I understood now... Thank you all for your responses.. Niral Perrin Harkins wrote: > > On Thu, 18 May 2000, Niral Trivedi wrote: > > Now, with Apache::DBI, we'll have one DBI handle per child process > > during the server startup. Now, let's say one child has started its > > processing and hasn't served any request yet. Now, first request comes > > in and it will look for DB handle, which is available and start > > processing it. Now, second request comes in for same child process and > > request for DBI handle, which is still serving first request. > > Niral, you're not understanding Apache's multi-process daemon > approach. No child process will ever try to serve more than > request at once. These are not multi-threaded processes. > > - Perrin
Re: Confusion on Apache::DBI
On Thu, 18 May 2000, Niral Trivedi wrote: > Now, with Apache::DBI, we'll have one DBI handle per child process > during the server startup. Now, let's say one child has started its > processing and hasn't served any request yet. Now, first request comes > in and it will look for DB handle, which is available and start > processing it. Now, second request comes in for same child process and > request for DBI handle, which is still serving first request. Niral, you're not understanding Apache's multi-process daemon approach. No child process will ever try to serve more than request at once. These are not multi-threaded processes. - Perrin
RE: Confusion on Apache::DBI
> -Original Message- > From: Niral Trivedi [mailto:[EMAIL PROTECTED]] > Sent: Thursday, May 18, 2000 3:57 PM > To: Geoffrey Young > Cc: '[EMAIL PROTECTED]' > Subject: Re: Confusion on Apache::DBI > > > Geoff, > > I know, once child dies, db handle goes out of scope and DBI cleans up > the connection.. > > What I was asking is, we have directive called > 'MaxRequestPerChild' for > Apache server configuration which basically says how many request one > child can process before it dies. So, if we have in 'httpd.conf' file > 'MaxRequestPerChild 1000', that means, one child process will > serv 1000 > request and then it will die. > > Now, with Apache::DBI, we'll have one DBI handle per child process > during the server startup. Now, let's say one child has started its > processing and hasn't served any request yet. Now, first request comes > in and it will look for DB handle, which is available and start > processing it. Now, second request comes in for same child process and > request for DBI handle, which is still serving first request. how would the child be available to serve another request but not have completed its DBI work? are you forking off a new process or something? > So, what > happened at this time to second request?? Does it have to wait for DBI > handle to be free?? That's my question.. > > I think, second request has to wait.. i.e. it will be the > same as normal > CGI.. only difference is, we'll save overhead of opening a DB > connection > each time request comes in.. Correct me if I am wrong.. > > And I'll look in DBI::Proxy .. > > Thanks again for your help Geoff.. > > Niral > > Geoffrey Young wrote: > > > > > -----Original Message- > > > From: Niral Trivedi [mailto:[EMAIL PROTECTED]] > > > Sent: Thursday, May 18, 2000 3:15 PM > > > To: Geoffrey Young > > > Cc: '[EMAIL PROTECTED]' > > > Subject: Re: Confusion on Apache::DBI > > > > > > > > > Thanks Geoff, > > > > > > You were right... I was using > "DBI:mysql:DBNAME::localhost" as connect > > > string in startup file whereas "DBI:mysql:DBNAME" in my mod_perl > > > script.. I have changed that and it worked... > > > > > > Now, another question.. As we agreed, we can have as many > db handle > > > available as server processes are running.. > > > > > > Now, can we set number of db connection per server process > > > in script or > > > in startup script or any other way??? > > > > > > Because what I see is in this way... Let's say a child process can > > > handle 10 request and then dies.. now it has one db connection > > > available.. > > > > I believe that once the child dies, $dbh goes out of scope > and DBI cleans up > > the connection. I could be wrong, though... > > > > > and it is processing one request which uses available db > > > handle.. now what happen if another request comes in and ask > > > for same db > > > handle??? > > > > well, another request won't come in and ask for the _same_ > handle that died > > with the other child - that's the nature of Apache::DBI, > one handle per > > child. It's not a pool of shared connections, really... > Apache will either > > serve the new request to an existing child (which would get a cached > > connection) or initialize a new child (which would > subsequently open a new > > connection and cache it)... > > > > > does that request has to wait for that or what??? > > > If yes, then > > > is there any way we can set number of connection per > process?? I mean > > > each child process can have 5 db connection open at the same > > > time.. and > > > it can grow upto 10.. So, if all 5 db handle are in use, > and if 6th > > > request comes in then process will open another connetion and > > > it can do > > > like this upto max of 10 connection.. > > > > > > Is it possible??? has anybody done this kind of things before > > > > folks have talked about this type of stuff on the dbi-users > list - it comes > > up every so often... > > > > I don't know that anyone has implemented a solution, though > you might try > > looking at DBI::ProxyServer - I think it does something > like this (though I > > haven't looked at it myself) > > > > --Geoff > > > > > > > > Thanks again for your help.. > > > > > > Niral > > > > > > Geoffrey Young wrote: > > > > > > >> > > > >> >
Re: Confusion on Apache::DBI
Geoff, I know, once child dies, db handle goes out of scope and DBI cleans up the connection.. What I was asking is, we have directive called 'MaxRequestPerChild' for Apache server configuration which basically says how many request one child can process before it dies. So, if we have in 'httpd.conf' file 'MaxRequestPerChild 1000', that means, one child process will serv 1000 request and then it will die. Now, with Apache::DBI, we'll have one DBI handle per child process during the server startup. Now, let's say one child has started its processing and hasn't served any request yet. Now, first request comes in and it will look for DB handle, which is available and start processing it. Now, second request comes in for same child process and request for DBI handle, which is still serving first request. So, what happened at this time to second request?? Does it have to wait for DBI handle to be free?? That's my question.. I think, second request has to wait.. i.e. it will be the same as normal CGI.. only difference is, we'll save overhead of opening a DB connection each time request comes in.. Correct me if I am wrong.. And I'll look in DBI::Proxy .. Thanks again for your help Geoff.. Niral Geoffrey Young wrote: > > > -Original Message- > > From: Niral Trivedi [mailto:[EMAIL PROTECTED]] > > Sent: Thursday, May 18, 2000 3:15 PM > > To: Geoffrey Young > > Cc: '[EMAIL PROTECTED]' > > Subject: Re: Confusion on Apache::DBI > > > > > > Thanks Geoff, > > > > You were right... I was using "DBI:mysql:DBNAME::localhost" as connect > > string in startup file whereas "DBI:mysql:DBNAME" in my mod_perl > > script.. I have changed that and it worked... > > > > Now, another question.. As we agreed, we can have as many db handle > > available as server processes are running.. > > > > Now, can we set number of db connection per server process > > in script or > > in startup script or any other way??? > > > > Because what I see is in this way... Let's say a child process can > > handle 10 request and then dies.. now it has one db connection > > available.. > > I believe that once the child dies, $dbh goes out of scope and DBI cleans up > the connection. I could be wrong, though... > > > and it is processing one request which uses available db > > handle.. now what happen if another request comes in and ask > > for same db > > handle??? > > well, another request won't come in and ask for the _same_ handle that died > with the other child - that's the nature of Apache::DBI, one handle per > child. It's not a pool of shared connections, really... Apache will either > serve the new request to an existing child (which would get a cached > connection) or initialize a new child (which would subsequently open a new > connection and cache it)... > > > does that request has to wait for that or what??? > > If yes, then > > is there any way we can set number of connection per process?? I mean > > each child process can have 5 db connection open at the same > > time.. and > > it can grow upto 10.. So, if all 5 db handle are in use, and if 6th > > request comes in then process will open another connetion and > > it can do > > like this upto max of 10 connection.. > > > > Is it possible??? has anybody done this kind of things before > > folks have talked about this type of stuff on the dbi-users list - it comes > up every so often... > > I don't know that anyone has implemented a solution, though you might try > looking at DBI::ProxyServer - I think it does something like this (though I > haven't looked at it myself) > > --Geoff > > > > > Thanks again for your help.. > > > > Niral > > > > Geoffrey Young wrote: > > > > >> > > >>
RE: Confusion on Apache::DBI
> -Original Message- > From: Niral Trivedi [mailto:[EMAIL PROTECTED]] > Sent: Thursday, May 18, 2000 3:15 PM > To: Geoffrey Young > Cc: '[EMAIL PROTECTED]' > Subject: Re: Confusion on Apache::DBI > > > Thanks Geoff, > > You were right... I was using "DBI:mysql:DBNAME::localhost" as connect > string in startup file whereas "DBI:mysql:DBNAME" in my mod_perl > script.. I have changed that and it worked... > > Now, another question.. As we agreed, we can have as many db handle > available as server processes are running.. > > Now, can we set number of db connection per server process > in script or > in startup script or any other way??? > > Because what I see is in this way... Let's say a child process can > handle 10 request and then dies.. now it has one db connection > available.. I believe that once the child dies, $dbh goes out of scope and DBI cleans up the connection. I could be wrong, though... > and it is processing one request which uses available db > handle.. now what happen if another request comes in and ask > for same db > handle??? well, another request won't come in and ask for the _same_ handle that died with the other child - that's the nature of Apache::DBI, one handle per child. It's not a pool of shared connections, really... Apache will either serve the new request to an existing child (which would get a cached connection) or initialize a new child (which would subsequently open a new connection and cache it)... > does that request has to wait for that or what??? > If yes, then > is there any way we can set number of connection per process?? I mean > each child process can have 5 db connection open at the same > time.. and > it can grow upto 10.. So, if all 5 db handle are in use, and if 6th > request comes in then process will open another connetion and > it can do > like this upto max of 10 connection.. > > Is it possible??? has anybody done this kind of things before folks have talked about this type of stuff on the dbi-users list - it comes up every so often... I don't know that anyone has implemented a solution, though you might try looking at DBI::ProxyServer - I think it does something like this (though I haven't looked at it myself) --Geoff > > Thanks again for your help.. > > Niral > > Geoffrey Young wrote: > > >> > >> >
Re: Confusion on Apache::DBI
Thanks Geoff, You were right... I was using "DBI:mysql:DBNAME::localhost" as connect string in startup file whereas "DBI:mysql:DBNAME" in my mod_perl script.. I have changed that and it worked... Now, another question.. As we agreed, we can have as many db handle available as server processes are running.. Now, can we set number of db connection per server process in script or in startup script or any other way??? Because what I see is in this way... Let's say a child process can handle 10 request and then dies.. now it has one db connection available.. and it is processing one request which uses available db handle.. now what happen if another request comes in and ask for same db handle??? does that request has to wait for that or what??? If yes, then is there any way we can set number of connection per process?? I mean each child process can have 5 db connection open at the same time.. and it can grow upto 10.. So, if all 5 db handle are in use, and if 6th request comes in then process will open another connetion and it can do like this upto max of 10 connection.. Is it possible??? has anybody done this kind of things before Thanks again for your help.. Niral Geoffrey Young wrote: >> >>
RE: Confusion on Apache::DBI
> -Original Message- > From: Niral Trivedi [mailto:[EMAIL PROTECTED]] > Sent: Thursday, May 18, 2000 1:11 PM > To: '[EMAIL PROTECTED]' > Subject: Confusion on Apache::DBI > > > All, > > Sorry if this question sounds stupid.. but I am new to mod_perl and > Apache::DBI.. I have successfully installed Apache Server 1.3.12 and > mod_perl 1.24 and Apache::DBI 0.87 on Solaris 2.7. > > And I have tested all successfully... But confusion arised when I > created a startup.pl file and tried to initiate DB connection in > startup.pl file using 'connect_on_init' from Apache::DBI > > As I understood, if you have 'connect_on_init' in startup > file, you have > preloaded DB handle when first request comes in. And you don't need to > open new db connection... But if I check the error_log file, I still > have entry saying something like following: Apache::DBI caches by connect-string, so make sure that your DBI->connect call is identical to your Apache::DBI->connect_on_init call, including all the extra parameters. > > 10803 Apache::DBI need ping: yes > 10803 Apache::DBI new connect to > 'DatabaseNameUsernamePasswordAutoCommit=1PrintError=1' > 10803 Apache::DBI disconnect (overloaded) > > And I will get this for first 4-5 request but after that each > time I am > getting are you sure that these 4-5 requests are for the same child? pay close attention to the pid... > > 10803 Apache::DBI need ping: yes > 10803 Apache::DBI already connected to > 'DatabaseNameUsernamePasswordAutoCommit=1PrintError=1' > 10803 Apache::DBI disconnect (overloaded) > > Why is that??? Shouldn't I supposed to get 'already connected to' > statement right from the first request yes, so long as you called connect_on_init properly. but don't forget, when a child is born, you'll get the 'new connect' output. connect doesn't happen at startup, per-se. that is, the parent process doesn't cache the handle, the child does... > > And how many open connection can I have at the same time?? As per my > understood, for Apache::DBI connection pooling is based per server > process. So, I guess as many server process you have, you can have db > connection handle open at the same time.. AM I RIGHT HERE? yes, you will have as many database handles as you have httpd children... HTH --Geoff > > Please clear my doubts on this... > > And thanks for your help ... > > Niral >
Confusion on Apache::DBI
All, Sorry if this question sounds stupid.. but I am new to mod_perl and Apache::DBI.. I have successfully installed Apache Server 1.3.12 and mod_perl 1.24 and Apache::DBI 0.87 on Solaris 2.7. And I have tested all successfully... But confusion arised when I created a startup.pl file and tried to initiate DB connection in startup.pl file using 'connect_on_init' from Apache::DBI As I understood, if you have 'connect_on_init' in startup file, you have preloaded DB handle when first request comes in. And you don't need to open new db connection... But if I check the error_log file, I still have entry saying something like following: 10803 Apache::DBI need ping: yes 10803 Apache::DBI new connect to 'DatabaseNameUsernamePasswordAutoCommit=1PrintError=1' 10803 Apache::DBI disconnect (overloaded) And I will get this for first 4-5 request but after that each time I am getting 10803 Apache::DBI need ping: yes 10803 Apache::DBI already connected to 'DatabaseNameUsernamePasswordAutoCommit=1PrintError=1' 10803 Apache::DBI disconnect (overloaded) Why is that??? Shouldn't I supposed to get 'already connected to' statement right from the first request And how many open connection can I have at the same time?? As per my understood, for Apache::DBI connection pooling is based per server process. So, I guess as many server process you have, you can have db connection handle open at the same time.. AM I RIGHT HERE? Please clear my doubts on this... And thanks for your help ... Niral
Re: Q: DBMS update framework for use within Apache::DBI?
>>>>> "Gunther" == Gunther Birznieks <[EMAIL PROTECTED]> writes: Gunther> This first criteria seems a tad odd to me. What business Gunther> scenario is there for this? Gunther> To me, when a user issues an update they expect that the Gunther> record exists. In a way, if the record does NOT exist, then Gunther> you are really going against your rule #2. That is, if they Gunther> issue an update and the record no longer exists, then that Gunther> is also a change to the record that someone did (a Gunther> deletion) and you are effectively overriding someone elses Gunther> deletion. The framework is to support an intranet time tracking application. The business rules of the system dictate there are no deletions of previously submitted time ... only inserts/updates. Therefore I can say without question that an existing time record will *always* exist (a modify), albeit in a potentially 'dirty' state (rule #2). Furthermore, if a particular time period has not been accounted for, i.e. no time record has been previously submitted, a default time record will be presented for modification, and subsequent submission (an insert). This is seamless to the client requesting the period. If there is no default time record available, then a 0-hour time record is presented for modification/submission (also an insert). Gunther> An application which implements #2 and is accelerated when Gunther> used with mod_perl (Apache::Registry) and Apache::DBI is Gunther> our latest version of WebDB. You may download a copy at Gunther> http://www.extropia.com/ and click on download button at Gunther> the top upper right)... Thank you for the pointer. I will *gleefully* investigate its offerings. | Hope this helps, | Gunther I'll let you know ... Peace.
Re: Q: DBMS update framework for use within Apache::DBI?
At 12:16 PM 5/17/00 -0600, Bruce W. Hoylman wrote: >Ciao! > >I am searching for the makings of a framework built around or within >mod_perl/Apache::DBI that supports the consistent update of a record >within a database. Primarily I am wanting to ensure read/write >integrity between database accesses by the web client, meaning I wish to >ensure the record about to be updated meets the following criteria: > > 1) It exists. If it does not, perform an insert instead > 2) If it exists, check that it is unchanged from the time the web >client first retrieved it for update. If it has changed, throw >an exception. I do not want a "last update wins" situation. This first criteria seems a tad odd to me. What business scenario is there for this? To me, when a user issues an update they expect that the record exists. In a way, if the record does NOT exist, then you are really going against your rule #2. That is, if they issue an update and the record no longer exists, then that is also a change to the record that someone did (a deletion) and you are effectively overriding someone elses deletion. >This is being done in an mod_perl/embperl/Apache::DBI environment. > >Suggestions or pointers to additional information would be greatly >appreciated. > >Peace. An application which implements #2 and is accelerated when used with mod_perl (Apache::Registry) and Apache::DBI is our latest version of WebDB. You may download a copy at http://www.extropia.com/ and click on download button at the top upper right)... If you want to read about it, the docs are located at http://www.extropia.com/docs/webdb/. Actually it was all generated using Stas Bekman's mod_perl guide generator (except using my pods instead of Stas's mod_perl guide pods) The WebDB will do #2 for you and, in fact, allows configuring the strategy of updates... eg you can choose to check all fields for changes, a subset of fields for changes, or just "key fields" for changes... similar to the PowerBuilder DataWindow model of handling client-server updates. This is done through the use of Extropia::DataSource which is a library that abstracts this stuff away. By default, WebDB is distributed to be configured to use Extropia::DataSource::File, but you just need to take out the file specific stuff from the config and then replace -TYPE => 'File' with -TYPE => "DBI" and add -DSNAME => 'dbi:yourdatabase etc..." and you are pretty much off and running. So the caveat is that the app is configured by default to work on any CGI/Perl environment. But it has been architected to take advantage of mod_perl's benefits (eg Apache::DBI) by just changing config parameters in the setup file. Since all the new extropia apps follow this common architecture, we have documented the mod_perl specific tuning issues in the Advanced Chapter of the Extropia Apps Guide (a supplement to the WebDB Guide) located at http://www.extropia.com/docs/extropia_app/ If you don't like WebDB itself and need to write your own logic, then you may want to just use Extropia::DataSource by itself (which implements the logic you want as an object but no CGI workflow exists around it). The documentation and code for that set is located at http://www.extropia.com/ExtropiaObjects/ Hope this helps, Gunther __ Gunther Birznieks ([EMAIL PROTECTED]) Extropia - The Web Technology Company http://www.extropia.com/
Q: DBMS update framework for use within Apache::DBI?
Ciao! I am searching for the makings of a framework built around or within mod_perl/Apache::DBI that supports the consistent update of a record within a database. Primarily I am wanting to ensure read/write integrity between database accesses by the web client, meaning I wish to ensure the record about to be updated meets the following criteria: 1) It exists. If it does not, perform an insert instead 2) If it exists, check that it is unchanged from the time the web client first retrieved it for update. If it has changed, throw an exception. I do not want a "last update wins" situation. This is being done in an mod_perl/embperl/Apache::DBI environment. Suggestions or pointers to additional information would be greatly appreciated. Peace.
Re: Apache::DBI and autocommit
On Tue, 16 May 2000, William Deegan wrote:
> Greetings,
>
> from the various perldocs and web pages I understand the following
> to be true.
>
> If autocommit is not set and a script exits the transaction will be
> rolled
> back.
>
> The question I have is when the database handle is re-used will the
> autocommit still be unset if the script that set it errors out?
No. What you need to do is use an exception handler around your code (see
the guide/perl.html) and commit if your code ran OK, or rollback if
not. Here's how I do it (sort of - there's more code to it than this):
eval {
dispatch();
};
if ($@) {
rollback;
output('errorpage.template', $@->value);
return OK;
}
return OK;
However also ensure that your transaction handling is fine grained at the
level its happening. I use DBIx::AnyDBD so that I can do this:
$db->begin_tran;
$db->do_stuff; # calls die() if it fails
# non-db stuff that calls die() if it fails
$db->commit;
--
Fastnet Software Ltd. High Performance Web Specialists
Providing mod_perl, XML, Sybase and Oracle solutions
Email for training and consultancy availability.
http://sergeant.org http://xml.sergeant.org
RE: Apache::DBI and autocommit
> -Original Message- > From: Perrin Harkins [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, May 16, 2000 10:32 PM > To: William Deegan > Cc: [EMAIL PROTECTED] > Subject: Re: Apache::DBI and autocommit > > > On Tue, 16 May 2000, William Deegan wrote: > > If autocommit is not set and a script exits the transaction will be > > rolled back. > > > > The question I have is when the database handle is re-used will the > > autocommit still be unset if the script that set it errors out? > > Yes, Apache::DBI doesn't touch your autocommit settings. true, but Apache::DBI caches connections per connect string, so a database handle called with AutoCommit=0 in one script and AutoCommit=1 in another will result in two cached handles. William - are you creating a $dbh and setting AutoCommit in a seperate step/script? If so, I'm not sure that the new AutoCommit attribute will be a part of the cached database handle, regardless of the exit status of the script. Can anyone confirm this? --Geoff > > - Perrin >
Re: Apache::DBI and autocommit
On Tue, 16 May 2000, William Deegan wrote: > If autocommit is not set and a script exits the transaction will be > rolled back. > > The question I have is when the database handle is re-used will the > autocommit still be unset if the script that set it errors out? Yes, Apache::DBI doesn't touch your autocommit settings. - Perrin
Apache::DBI and autocommit
Greetings, from the various perldocs and web pages I understand the following to be true. If autocommit is not set and a script exits the transaction will be rolled back. The question I have is when the database handle is re-used will the autocommit still be unset if the script that set it errors out? -Bill begin:vcard n:Deegan;William tel;fax:650-413-1355 tel;work:650-598-3858 x-mozilla-html:FALSE url:http://www.iescrow.com org:iEscrow,Inc. version:2.1 email;internet:[EMAIL PROTECTED] title:Web Site Operations Manager adr;quoted-printable:;;2600 Bridge Parkway=0D=0ASuite 201;Redwood Shores;CA;94065; note;quoted-printable:Work:=0D=0Ahttp://www.iescrow.com=0D=0A=0D=0APersonal:=0D=0Ahttp://www.hitmyspot.com x-mozilla-cpt:;-19264 fn:William Deegan end:vcard
Re: Apache::DBI->connect_on_init in BEGIN?
> the problem is i can't seem to find a way to get configration variables > from httpd.conf inside a BEGIN or a PerlChildInitHandler. i set the > variables with PerlSetVar inside sections. use Apache->server->dir_config as eric already suggested to you. you'll have to move the PerlSetVar outside of though. you can use PerlSetEnv too.
Re: Apache::DBI->connect_on_init in BEGIN?
Doug MacEachern wrote: > > > connect_on_init was written to be a PerlChildInitHandler, it doesn't make > sense to use it anywhere else. ok, that would accomplish pretty much the same thing i guess. the problem is i can't seem to find a way to get configration variables from httpd.conf inside a BEGIN or a PerlChildInitHandler. i set the variables with PerlSetVar inside sections. is there any way to do this? -- Svante Sörmark | Chalmers University IT systems & services | 031-7728665
Re: Apache::DBI->connect_on_init in BEGIN?
On Sun, 14 May 2000, svante [iso-8859-1] sörmark wrote:
> hi all,
>
> what i'd like to do is "pre-initialize" my DBI connections from whithin
> my PerlHandler's BEGIN block.
>
> something like this:
> BEGIN {
> if ( Apache->dir_config('CONNECT_ON_INIT') {
> Apache::DBI->connect_on_init(Apache->dir_config('DBI_INFO');
> }
> }
connect_on_init was written to be a PerlChildInitHandler, it doesn't make
sense to use it anywhere else.
RE: Apache::DBI->connect_on_init in BEGIN?
> hi all,
>
> what i'd like to do is "pre-initialize" my DBI connections from whithin
> my PerlHandler's BEGIN block.
>
> something like this:
> BEGIN {
> if ( Apache->dir_config('CONNECT_ON_INIT') {
> Apache::DBI->connect_on_init(Apache->dir_config('DBI_INFO');
> }
> }
>
> but of course the Apache* stuff isn't available at this stage...
you should be able to use Apache->server->dir_config('foo')
at this point. Doesn't work with per-vhost config variables, unfortunately.
Please do let me know if this works for you.
--
Eric
Re: Apache::DBI->connect_on_init in BEGIN?
I guess I don't know enough about your specific case. :)
On the systems I work on, I use "PerlRequire startup.pl" prior to loading
anything else so that I can use the connection in subsequent code. Seems to
work out fine for what I'm doing.
--Jeff
At 05:30 PM 5/14/00, svante sörmark wrote:
>yeah, i know about startup.pl, and i have been using it until now,
>but the goal here was to avoid having to put the same configuration
>in two different files :).
>
>Jeff Beard wrote:
> >
> > Checkout the sample startup.pl that comes with Apache::DBI.
> >
> > --Jeff
> >
> > At 05:08 PM 5/14/00, svante sörmark wrote:
> > >hi all,
> > >
> > >what i'd like to do is "pre-initialize" my DBI connections from whithin
> > >my PerlHandler's BEGIN block.
> > >
> > >something like this:
> > >BEGIN {
> > > if ( Apache->dir_config('CONNECT_ON_INIT') {
> > >
> Apache::DBI->connect_on_init(Apache->dir_config('DBI_INFO');
> > > }
> > >}
> > >
> > >but of course the Apache* stuff isn't available at this stage...
> > >
> > >does anyone have a clever solution to this? i've resorted to `grep`ing
> > >httpd.conf for the DBI_INFO string, but that is sooo ugly.
> > >
> > >thanks.
> > >--
> > >
> > >Svante Sörmark | Chalmers University IT systems & services | 031-7728665
> > >
> >
> > Jeff Beard
> > _
> > Web:www.cyberxape.com
> > Email: jeff at cyberxape.com
> > Location: Boulder, CO, USA
>
>--
>
>Svante Sörmark | Chalmers University IT systems & services | 031-7728665
>
Jeff Beard
_
Web:www.cyberxape.com
Email: jeff at cyberxape.com
Location: Boulder, CO, USA
Re: Apache::DBI->connect_on_init in BEGIN?
yeah, i know about startup.pl, and i have been using it until now,
but the goal here was to avoid having to put the same configuration
in two different files :).
Jeff Beard wrote:
>
> Checkout the sample startup.pl that comes with Apache::DBI.
>
> --Jeff
>
> At 05:08 PM 5/14/00, svante sörmark wrote:
> >hi all,
> >
> >what i'd like to do is "pre-initialize" my DBI connections from whithin
> >my PerlHandler's BEGIN block.
> >
> >something like this:
> >BEGIN {
> > if ( Apache->dir_config('CONNECT_ON_INIT') {
> > Apache::DBI->connect_on_init(Apache->dir_config('DBI_INFO');
> > }
> >}
> >
> >but of course the Apache* stuff isn't available at this stage...
> >
> >does anyone have a clever solution to this? i've resorted to `grep`ing
> >httpd.conf for the DBI_INFO string, but that is sooo ugly.
> >
> >thanks.
> >--
> >
> >Svante Sörmark | Chalmers University IT systems & services | 031-7728665
> >
>
> Jeff Beard
> _
> Web:www.cyberxape.com
> Email: jeff at cyberxape.com
> Location: Boulder, CO, USA
--
Svante Sörmark | Chalmers University IT systems & services | 031-7728665
Re: Apache::DBI->connect_on_init in BEGIN?
Checkout the sample startup.pl that comes with Apache::DBI.
--Jeff
At 05:08 PM 5/14/00, svante sörmark wrote:
>hi all,
>
>what i'd like to do is "pre-initialize" my DBI connections from whithin
>my PerlHandler's BEGIN block.
>
>something like this:
>BEGIN {
> if ( Apache->dir_config('CONNECT_ON_INIT') {
> Apache::DBI->connect_on_init(Apache->dir_config('DBI_INFO');
> }
>}
>
>but of course the Apache* stuff isn't available at this stage...
>
>does anyone have a clever solution to this? i've resorted to `grep`ing
>httpd.conf for the DBI_INFO string, but that is sooo ugly.
>
>thanks.
>--
>
>Svante Sörmark | Chalmers University IT systems & services | 031-7728665
>
Jeff Beard
_
Web:www.cyberxape.com
Email: jeff at cyberxape.com
Location: Boulder, CO, USA
Apache::DBI->connect_on_init in BEGIN?
hi all,
what i'd like to do is "pre-initialize" my DBI connections from whithin
my PerlHandler's BEGIN block.
something like this:
BEGIN {
if ( Apache->dir_config('CONNECT_ON_INIT') {
Apache::DBI->connect_on_init(Apache->dir_config('DBI_INFO');
}
}
but of course the Apache* stuff isn't available at this stage...
does anyone have a clever solution to this? i've resorted to `grep`ing
httpd.conf for the DBI_INFO string, but that is sooo ugly.
thanks.
--
Svante Sörmark | Chalmers University IT systems & services | 031-7728665
Re: Apache::DBI with Sybase - What's wrong?
"Graf, Chris" schrieb: > Thanks Michael. > > If anyone can explain a little better what Apache::DBI and mod_perl are > doing, or should be doing at this point, that may be helpful. I have been > testing a little more and found that no errors will appear unless I am > actually doing something with the connections. If I just initiate the > persistent connections the first time the scripts run, and never touch them, > they appear to stay alive (or at least restart properly) without generating > errors. Hy, I had serious sockket/connect porblems too ;-(( that was using 11.0.3. I changed to 11.9.2 and now everything is fine (Everything on RedHat 6.2). My problem was somewhere in the clientlibrary : let's say a couple of hundred/thousand queries went fine. Than my application stopped running. The Process in the database (sp_who) was existing, and killing the DB-connection caused the client to die. ;-)) Maybe it's worth to try an upgrade if you are running 11.0.3 ... regards Fred
RE: Apache::DBI with Sybase - What's wrong?
Thanks Michael. If anyone can explain a little better what Apache::DBI and mod_perl are doing, or should be doing at this point, that may be helpful. I have been testing a little more and found that no errors will appear unless I am actually doing something with the connections. If I just initiate the persistent connections the first time the scripts run, and never touch them, they appear to stay alive (or at least restart properly) without generating errors. If I do queries against the connections, they will start to generate these errors starting about 15 mins after Apache startup (with about 100-150 httpd processes running at any given time). The errors will become more and more frequent after they start, which leads me to believe that when the connection goes bad in an httpd process, it doesn't correct itself. I also have two other Apache::DBI connections to a MySQL server running in the same connect sub which never have a problem. Here is the exact complete error log in sequence from the time I started Apache until I shut it down. The first error appeared about 15 mins after restart. The rest happened within about a minute after the first one. --- Apache startup ct_cmd_alloc failed at /home/httpd/uoboards/cgi-bin/w3t.pm line 1322. DBD::Sybase::st execute failed: OpenClient message: LAYER = (1) ORIGIN = (1) SEVERITY = (1) NUMBER = (50) Message String: ct_cmd_alloc(): user api layer: external error: The connection has been marked dead. ct_cmd_alloc failed at /usr/local/lib/perl5/site_perl/5.005/sun4-solaris/DBD/Sybase.pm line 159. DBD::Sybase::db ping failed: OpenClient message: LAYER = (5) ORIGIN = (3) SEVERITY = (5) NUMBER = (6) Message String: ct_cancel(): network packet layer: internal net library error: Net-Library operation terminated due to disconnect ct_cmd_alloc failed at /usr/local/lib/perl5/site_perl/5.005/sun4-solaris/DBD/Sybase.pm line 159. DBD::Sybase::db ping failed: OpenClient message: LAYER = (5) ORIGIN = (3) SEVERITY = (5) NUMBER = (6) Message String: ct_cancel(): network packet layer: internal net library error: Net-Library operation terminated due to disconnect ct_cmd_alloc failed at /usr/local/lib/perl5/site_perl/5.005/sun4-solaris/DBD/Sybase.pm line 159. DBD::Sybase::db ping failed: OpenClient message: LAYER = (5) ORIGIN = (3) SEVERITY = (5) NUMBER = (6) Message String: ct_cancel(): network packet layer: internal net library error: Net-Library operation terminated due to disconnect DBD::Sybase::db ping failed: OpenClient message: LAYER = (1) ORIGIN = (1) SEVERITY = (1) NUMBER = (60) Message String: ct_cancel(CONN,ALL): user api layer: external error: There is a usage error. This routine has been called at an illegal time. OpenClient message: LAYER = (1) ORIGIN = (1) SEVERITY = (1) NUMBER = (60) Message String: ct_close(FORCE): user api layer: external error: There is a usage error. This routine has been called at an illegal time. DBD::Sybase::db ping failed: OpenClient message: LAYER = (1) ORIGIN = (1) SEVERITY = (1) NUMBER = (60) Message String: ct_cancel(CONN,ALL): user api layer: external error: There is a usage error. This routine has been called at an illegal time. OpenClient message: LAYER = (1) ORIGIN = (1) SEVERITY = (1) NUMBER = (60) Message String: ct_close(FORCE): user api layer: external error: There is a usage error. This routine has been called at an illegal time. DBD::Sybase::db ping failed: OpenClient message: LAYER = (1) ORIGIN = (1) SEVERITY = (1) NUMBER = (60) Message String: ct_cancel(CONN,ALL): user api layer: external error: There is a usage error. This routine has been called at an illegal time. OpenClient message: LAYER = (1) ORIGIN = (1) SEVERITY = (1) NUMBER = (60) Message String: ct_close(FORCE): user api layer: external error: There is a usage error. This routine has been called at an illegal --- shutdown occurs here syb_db_disconnect(): ct_con_drop() failed syb_db_disconnect(): ct_con_drop() faile Thanks > > It seems that once processes start getting reused, I wind up with a ton of > DB error messages in my error_log. > > They seem to start like this: > > ct_cmd_alloc failed at > /usr/local/lib/perl5/site_perl/5.005/sun4-solaris/DBD/Sybase.pm line 159. > DBD::Sybase::db ping failed: OpenClient message: LAYER = (5) ORIGIN = (3) > SEVERITY = (5) NUMBER = (6) > Message String: ct_cancel(): network packet layer: internal net library > error: Net-Library operation terminated due to disconnect I'm not familiar with Apache::DBI, so I don't know exactly in what situation it calls ping()... In this case it looks like ping fails (ie the connection to the server has been killed) but the sequence of calls that follow is incorrect. > What is happening on the user end at this time - 500s? Any insight would be > incredibly helpful at this point. I think there's a good chance of 500s, but maybe not. It's possible that these are inte
Re: Apache::DBI with Sybase - What's wrong?
Graf, Chris writes: > > It seems that once processes start getting reused, I wind up with a ton of > DB error messages in my error_log. > > They seem to start like this: > > ct_cmd_alloc failed at > /usr/local/lib/perl5/site_perl/5.005/sun4-solaris/DBD/Sybase.pm line 159. > DBD::Sybase::db ping failed: OpenClient message: LAYER = (5) ORIGIN = (3) > SEVERITY = (5) NUMBER = (6) > Message String: ct_cancel(): network packet layer: internal net library > error: Net-Library operation terminated due to disconnect I'm not familiar with Apache::DBI, so I don't know exactly in what situation it calls ping()... In this case it looks like ping fails (ie the connection to the server has been killed) but the sequence of calls that follow is incorrect. > What is happening on the user end at this time - 500s? Any insight would be > incredibly helpful at this point. I think there's a good chance of 500s, but maybe not. It's possible that these are internal warnings, and that the initial failed ping() causes a database reconnect and that things continue cleanly... Michael -- Michael Peppler -||- Data Migrations Inc. [EMAIL PROTECTED]-||- http://www.mbay.net/~mpeppler Int. Sybase User Group -||- http://www.isug.com Sybase on Linux mailing list: [EMAIL PROTECTED]
Apache::DBI with Sybase - What's wrong?
It seems that once processes start getting reused, I wind up with a ton of DB error messages in my error_log. They seem to start like this: ct_cmd_alloc failed at /usr/local/lib/perl5/site_perl/5.005/sun4-solaris/DBD/Sybase.pm line 159. DBD::Sybase::db ping failed: OpenClient message: LAYER = (5) ORIGIN = (3) SEVERITY = (5) NUMBER = (6) Message String: ct_cancel(): network packet layer: internal net library error: Net-Library operation terminated due to disconnect Then a whole host of these start popping up: DBD::Sybase::db ping failed: OpenClient message: LAYER = (1) ORIGIN = (1) SEVERITY = (1) NUMBER = (60) Message String: ct_cancel(CONN,ALL): user api layer: external error: There is a usage error. This routine has been called at an illegal time. OpenClient message: LAYER = (1) ORIGIN = (1) SEVERITY = (1) NUMBER = (60) Message String: ct_close(FORCE): user api layer: external error: There is a usage error. This routine has been called at an illegal time. What is happening on the user end at this time - 500s? Any insight would be incredibly helpful at this point. Thanks Chris
RE: Apache::DBI
> -Original Message-
> From: Jim Serio [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, May 03, 2000 10:02 AM
> To: [EMAIL PROTECTED]
> Subject: Apache::DBI
>
>
> I'm not sure if this is even a problem but it's always
> been on my mind. I use Apache::DBI and I have a general
> module that handles db connections for my scripts. Here's
> the relevant portion:
>
> my $DBH ||= DBI->connect("...")
>
> It basically accepts a hash ref to the dbconfig and opens
> a connection. My httpd.conf is set with 5 spare clients
> MIN and 10 MAX.
>
> I'm the only one using this module right now and starting
> httpd fresh results in no conections. Running my test CGI
> script once results in two (2) mysql connections. Running
> it again, results in four (4) connections. This will
> eventually continue until the number of mysql connections
> is always four (4) more than httpd processes.
>
> The thing that I can't figure out is that my scripts
> properly open and close the db connection, so why doesn't
> Apache::DBI re-use the original connection? Why spawn
> one more each time?
try setting $Apache::DBI::DEBUG=2 to debug your connections.
any call to $dbh->disconnect is intercepted by Apache::DBI, thus no
disconnect ever really happens (which is the whole point to Apache::DBI)
Keep in mind that Apache::DBI will hold one connection per httpd child
process _per connect string_. That is, if you connect once with,say,
RAISE_ERROR=1 and once with RAISE_ERROR=0, Apache::DBI will create two
processes for that child.
HTH
--Geoff
>
> I've checked the FAQ and searched the archives and found
> no info (other than someone else asking this same question
> last year with no helpful answer) and the Apache:DBI man
> page doesn't touch on this.
>
> Jim
>
Re: Apache::DBI
> Are you sure it's not: > Opening connections with different parameters > http://perl.apache.org/guide/databases.html#Opening_connections_with_differe Oops. I forgot I had two seperate db accesses on this particular page and running with $Apache::DBI::DEBUG = 1 clued me in. So am I correct in saying that it will continue to open connections until connections = httpd processes? It seems like that's what's eventually happening. Jim
Re: Apache::DBI
On Wed, 3 May 2000, Jim Serio wrote:
> I'm not sure if this is even a problem but it's always
> been on my mind. I use Apache::DBI and I have a general
> module that handles db connections for my scripts. Here's
> the relevant portion:
>
> my $DBH ||= DBI->connect("...")
>
> It basically accepts a hash ref to the dbconfig and opens
> a connection. My httpd.conf is set with 5 spare clients
> MIN and 10 MAX.
>
> I'm the only one using this module right now and starting
> httpd fresh results in no conections. Running my test CGI
> script once results in two (2) mysql connections. Running
> it again, results in four (4) connections. This will
> eventually continue until the number of mysql connections
> is always four (4) more than httpd processes.
>
> The thing that I can't figure out is that my scripts
> properly open and close the db connection, so why doesn't
> Apache::DBI re-use the original connection? Why spawn
> one more each time?
>
> I've checked the FAQ and searched the archives and found
> no info (other than someone else asking this same question
> last year with no helpful answer) and the Apache:DBI man
> page doesn't touch on this.
Are you sure it's not:
Opening connections with different parameters
http://perl.apache.org/guide/databases.html#Opening_connections_with_differe
__
Stas Bekman | JAm_pH--Just Another mod_perl Hacker
http://stason.org/ | mod_perl Guide http://perl.apache.org/guide
mailto:[EMAIL PROTECTED] | http://perl.orghttp://stason.org/TULARC/
http://singlesheaven.com| http://perlmonth.com http://sourcegarden.org
--
Apache::DBI
I'm not sure if this is even a problem but it's always
been on my mind. I use Apache::DBI and I have a general
module that handles db connections for my scripts. Here's
the relevant portion:
my $DBH ||= DBI->connect("...")
It basically accepts a hash ref to the dbconfig and opens
a connection. My httpd.conf is set with 5 spare clients
MIN and 10 MAX.
I'm the only one using this module right now and starting
httpd fresh results in no conections. Running my test CGI
script once results in two (2) mysql connections. Running
it again, results in four (4) connections. This will
eventually continue until the number of mysql connections
is always four (4) more than httpd processes.
The thing that I can't figure out is that my scripts
properly open and close the db connection, so why doesn't
Apache::DBI re-use the original connection? Why spawn
one more each time?
I've checked the FAQ and searched the archives and found
no info (other than someone else asking this same question
last year with no helpful answer) and the Apache:DBI man
page doesn't touch on this.
Jim
Re: Apache::DBI disconnect?
On Mon, 24 Apr 2000, John S. Evans wrote: > Weird. The whole point of Apache::DBI (or so I understand it) is so that > your $dbh stays valid across CGI or Handler calls. Sure. But it does it magically. You're still supposed to call disconnect. That way, your code will also work without Apache::DBI. -- -- Tom Mornini -- InfoMania Printing and Prepress
Re: Apache::DBI disconnect?
"John S. Evans" wrote: > > Weird. The whole point of Apache::DBI (or so I understand it) is so that > your $dbh stays valid across CGI or Handler calls. That's right. The disconnect call is a no-op when using Apache::DBI. > I can only think of two reasons why I get the error message: > > 1) My child process is dying, and the DBI code is telling me that I never > called disconnect() on that $dbh. I don't think this is the case, since the > line (#119) in Apache::DBI that is referenced in the error is in the > connect() call. > > 2) My $dbh has timed out, and Apache::DBI is attempting to reconnect. The > code author decided not to perform a disconnect() because they knew the > connection was already timed out. Those are both good guesses. I'd say the latter as well. One of your db handles probably failed to ping and got removed. I wouldn't worry about it. - Perrin
Re: Apache::DBI disconnect?
Weird. The whole point of Apache::DBI (or so I understand it) is so that your $dbh stays valid across CGI or Handler calls. I can only think of two reasons why I get the error message: 1) My child process is dying, and the DBI code is telling me that I never called disconnect() on that $dbh. I don't think this is the case, since the line (#119) in Apache::DBI that is referenced in the error is in the connect() call. 2) My $dbh has timed out, and Apache::DBI is attempting to reconnect. The code author decided not to perform a disconnect() because they knew the connection was already timed out. I'm assuming that it's #2, but wanted to find out if other folks had seen this as well, since I don't normally see much in the error_log. -jse > From: Tom Mornini <[EMAIL PROTECTED]> > Date: Mon, 24 Apr 2000 22:42:49 -0700 (PDT) > To: "John S. Evans" <[EMAIL PROTECTED]> > Cc: modperl <[EMAIL PROTECTED]> > Subject: Re: Apache::DBI disconnect? > > On Mon, 24 Apr 2000, John S. Evans wrote: > >> Dang. That "delete" code is in the Apache::DBI code (Apache/DBI.pm line >> 119). Is this a known bug in Apache::DBI, then? > > No, I don't know of any problems with Apache::DBI. Typically the error > message that you are talking about happens when your $dbh goes > out-of-scope without an explicit disconnect. > > Are you disconnecting in your code? > > -- > -- Tom Mornini > -- InfoMania Printing and Prepress >
Re: Apache::DBI disconnect?
On Mon, 24 Apr 2000, John S. Evans wrote: > Dang. That "delete" code is in the Apache::DBI code (Apache/DBI.pm line > 119). Is this a known bug in Apache::DBI, then? No, I don't know of any problems with Apache::DBI. Typically the error message that you are talking about happens when your $dbh goes out-of-scope without an explicit disconnect. Are you disconnecting in your code? -- -- Tom Mornini -- InfoMania Printing and Prepress
Re: Apache::DBI disconnect?
Dang. That "delete" code is in the Apache::DBI code (Apache/DBI.pm line
119). Is this a known bug in Apache::DBI, then?
-jse
> From: Tom Mornini <[EMAIL PROTECTED]>
> Date: Mon, 24 Apr 2000 17:49:35 -0700 (PDT)
> To: "John S. Evans" <[EMAIL PROTECTED]>
> Subject: Re: Apache::DBI disconnect?
>
> On Mon, 24 Apr 2000, John S. Evans wrote:
>
>> Database handle destroyed without explicit disconnect at
>> /usr/local/lib/perl5/site_perl/5.005/Apache/DBI.pm line 119.
>>
>> The "offending" line of code is:
>>
>> delete $Connected{$Idx};
>>
>> Is this something I should worry about? I'm assuming that this is happening
>> because my DB connection has timed out, and we're deleting the old
>> connection before creating a new one.
>
> It's a bad thing. You need to disconnect i.e. (just guessing from the
> code)
>
> $Connect{$Idx}->disconnect;
>
> before the delete.
>
> --
> -- Tom Mornini
> -- InfoMania Printing and Prepress
>
