I've been away for a while, so I'm sorry if this reply is coming too
late, but if not then hopefully it helps...
Can you try changing the call to prepare() to prepare_cached() and
try again?
Also, I noticed that in the startup.pl script you included earlier
that there's no
Thanks Perrin.
The "end user" is getting the following:
HTTP/1.1 500 Internal Server Error
Date: Tue, 08 Oct 2024 20:17:24 GMT
Server: Apache/2.4.57 (AlmaLinux) OpenSSL/3.0.7 mod_perl/2.0.12 Perl/v5.32.1
Content-Length: 333
Connection: close
Content-Type: text/html; charset=iso-8859-1
Software e
DBI is supposed to install the driver when you call connect(), although
that does mean any code loaded there isn't shared in memory.
My question would be, did you get any actual failed responses in your load
test, or just these error log messages? If all the requests succeeded, then
I would suspec
Thanks Ed. I'll add it and see if it helps. My load testing phase is
already completed, but I may get a chance to retest next year.
On Thu, Oct 10, 2024 at 6:32 AM Edward J. Sabol
wrote:
> On Oct 7, 2024, at 5:55 PM, Tim Lank wrote:
>
> I have the following in my startup.pl:
>
> use CGI qw(:a
On Oct 7, 2024, at 5:55 PM, Tim Lank wrote:I have the following in my startup.pl:use CGI qw(:all);use CGI::Carp 'fatalsToBrowser', 'carpout';use List::Util 'shuffle';CGI->compile(':all');Apache::DBI->connect_on_init ("DBI:mysql:holidayshop",I don't know if it will help or not, but, before the abo
Nothing glaring turned up in the logs when DBI debugs were turned on.
Along the lines of what Mithun conveyed, I did add this to the /etc/my.cnf
and it has seemed to cut the amount of errors in half or less from 6-8 down
to 2 or 3 per run.
[mysqld]
default-authentication-plugin=mysql_native_passw
Good point. I’ll try to ratchet up the debugs on those to see if anything
pops out
On Mon, Oct 7, 2024 at 6:58 PM Adam Prime
wrote:
> You may need to dig into the code in DBI, or DBD::mysql to understand what
> is happening (or not happening) in the rare occasions that this occurs.
> Without th
You may need to dig into the code in DBI, or DBD::mysql to understand what is
happening (or not happening) in the rare occasions that this occurs. Without
the ability to consistently reproduce the issue all we can really do is look at
the code and make educated guesses.
Adam
On Oct 7, 2024, at
it doesn't seem to explain why it would work 99+% of the time though. I
don't think it applies to my situation exactlly
On Mon, Oct 7, 2024 at 6:31 PM Mithun Bhattacharya wrote:
> Maybe this helps ?
>
>
> https://php.watch/articles/fix-php-mysql-84-mysql_native_password-not-loaded
>
> On Mon, O
Maybe this helps ?
https://php.watch/articles/fix-php-mysql-84-mysql_native_password-not-loaded
On Mon, Oct 7, 2024, 4:56 PM Tim Lank wrote:
> Apache::DBI experts:
>
> I have the following in my startup.pl:
>
> use CGI qw(:all);
> use CGI::Carp 'fatalsToBrowser', 'carpout';
> use List::Util 'sh
These aren't formal benchmarks but, having just tried it on one of our
development systems, I can tell you that Apache2::DBI without pgbouncer is
slower than using pgbouncer without Apache2::DBI. Although, using both
seems to be marginally faster than either.
On Tue, Apr 22, 2014 at 12:36 PM, Per
Apache::DBI overrides DBI's connect() method so that you're using
persistent connections when you use DBI directly. It may be that your
performance improvement came from better management of Pg resources
with PgBouncer than from reducing connection overhead. You could test
it be removing Apache::
use Apache::DBI (); appears in our startup.pl but the application code uses
DBI directly.
On Tue, Apr 22, 2014 at 12:30 PM, Perrin Harkins wrote:
> Thanks John. Were you using Apache::DBI before PgBouncer?
> Apache::DBI would also eliminate the overhead of establishing new
> connections.
>
> -
Thanks John. Were you using Apache::DBI before PgBouncer?
Apache::DBI would also eliminate the overhead of establishing new
connections.
- Perrin
On Tue, Apr 22, 2014 at 12:23 PM, John Dunlap wrote:
> I can speak to your final point. I recently deployed PGBouncer into our
> production environme
I can speak to your final point. I recently deployed PGBouncer into our
production environment and, like the OP, we have separate web and database
servers. With PGBouncer running on the web server(you could also run it on
the database server if you wanted to) we noticed a dramatic increase in
perfo
Interesting. Why did you have to install PgBouncer? Can't Postgres
handle remote connections from your web server?
I don't use Postgres, but reading the description of PgBouncer I can
see some things you'd want to consider.
First, Apache::DBI prevents you from making persistent connections
befo
Apache::DBI caches database connection per process so you avoid the cost of
creating a connection on each requests.
Pgbouncer pools database connections so that you don't tie up one
postmaster process per httpd process.
If you only have one webserver you may not have a real need for pgbouncer;
it
I'd be interested in hearing about this too.
On Tue, Apr 22, 2014 at 10:02 AM, jbiskofski wrote:
> I just want to confirm something with all you smart folks.
>
> I recently separated my web servers from my database servers, before I was
> using Apache::DBI to maintain persistent connections bet
, 2013 9:57 AM
To: Xinhuan Zheng mailto:xzh...@christianbook.com>>
Cc: Adam Prime mailto:adam.pr...@utoronto.ca>>,
"modperl@perl.apache.org<mailto:modperl@perl.apache.org>"
mailto:modperl@perl.apache.org>>
Subject: Re: Apache::DBI connect
On Fri, Nov
On Fri, Nov 8, 2013 at 2:58 PM, Xinhuan Zheng wrote:
> The query is from the application code not the 'select 1' test query.
>
OK, then it seems like Apache::DBI may not have a problem.
> While most of time I saw Apache::DBI->connect is called but sometime from
> a process, it will print out it
Xinhuan Zheng mailto:xzh...@christianbook.com>>
Cc: Adam Prime mailto:adam.pr...@utoronto.ca>>,
"modperl@perl.apache.org<mailto:modperl@perl.apache.org>"
mailto:modperl@perl.apache.org>>
Subject: Re: Apache::DBI connect
On Thu, Nov 7, 2013 at 11:06 PM, Xinhuan Zheng
mai
On Thu, Nov 7, 2013 at 11:06 PM, Xinhuan Zheng wrote:
> As I turned on more debugging, when the problem occurs, the Apache cached
> connection reference is different than the database handle reference the
> query is using.
Which query are you talking about? The ping in Apache::DBI? Or somethin
mailto:adam.pr...@utoronto.ca>>,
"modperl@perl.apache.org<mailto:modperl@perl.apache.org>"
mailto:modperl@perl.apache.org>>
Subject: Re: Apache::DBI connect
That line stops it from running the ping if $needping is false. The "or" and
"||" operators in Perl
})) {
>
> What's the difference between the two? Why the code in favor of "or"
> instead of "and"?
>
> - xinhuan
>
> From: Perrin Harkins
> Date: Thursday, November 7, 2013 3:05 PM
>
> To: Xinhuan Zheng
> Cc: Adam Prime , "modperl@
m.pr...@utoronto.ca>>,
"modperl@perl.apache.org<mailto:modperl@perl.apache.org>"
mailto:modperl@perl.apache.org>>
Subject: Re: Apache::DBI connect
Sorry, I can't determine the problem from your log. You'll need to either run
it in the debugger or add some debuggi
: Xinhuan Zheng
> Cc: Adam Prime , "modperl@perl.apache.org" <
> modperl@perl.apache.org>
>
> Subject: Re: Apache::DBI connect
>
> It is in the DBI documentation. Search for "0E0".
>
> - Perrin
>
>
> On Thu, Nov 7, 2013 at 12:41 PM, Xinhuan Z
phark...@gmail.com>>
Date: Thursday, November 7, 2013 1:00 PM
To: Xinhuan Zheng mailto:xzh...@christianbook.com>>
Cc: Adam Prime mailto:adam.pr...@utoronto.ca>>,
"modperl@perl.apache.org<mailto:modperl@perl.apache.org>"
mailto:modperl@perl.apache.org>>
Subje
;On 13-11-07 11:29 AM, Xinhuan Zheng wrote:
> >> one correct - In both cases, the return value is evaluated to false.
> >>
> >> How do you distinguish?
> >>
> >> - xinhuan
> >>
> >> From: Xinhuan Zheng >> <mailto:xzh...@christ
t;> From: Xinhuan Zheng > <mailto:xzh...@christianbook.com>>
>> Date: Thursday, November 7, 2013 11:12 AM
>> To: Perrin Harkins mailto:phark...@gmail.com>>
>> Cc: mod_perl list ><mailto:modperl@perl.apache.org>>
>> Subject: Re: Apache::DB
return value is evaluated to false.
How do you distinguish?
- xinhuan
From: Xinhuan Zheng mailto:xzh...@christianbook.com>>
Date: Thursday, November 7, 2013 11:12 AM
To: Perrin Harkins mailto:phark...@gmail.com>>
Cc: mod_perl list mailto:modperl@perl.apache.org>>
Subject:
l.apache.org>>
Subject: Re: Apache::DBI connect
> I don't actually understand why you did that. What was wrong with the normal
> ping?
With Oracle DRCP, even though ping succeeds, the connection to the server
process is actually terminated. Or ora_ping() may return 0E0 "
don't understand that piece of code. I can't do the change. Hope you can help.
- xinhuan
From: Perrin Harkins mailto:phark...@gmail.com>>
Date: Thursday, November 7, 2013 11:00 AM
To: Xinhuan Zheng mailto:xzh...@christianbook.com>>
Cc: mod_perl list mailto:modperl@perl.apac
On Thu, Nov 7, 2013 at 9:46 AM, Xinhuan Zheng
wrote:
>The $ok is undef. In the case if the test does succeed (like the first
select), $ok returns 0E0.
That all sounds good. 0E0 is a true value in Perl. It means "zero but
true." And undef is a false value. You don't need to test for undef.
>
t. The Apache::DBI cached a dead database handle for
apache version 1.3.42 if startup.pl create a database handle. The apache child
processes inherits this dead handle. It doesn't cause application error but it
does take memory space. If there is many apache processes, that's not goo
(DBD ERROR: OCIStmtExecute).
>
> Process 3861 establishes a new connection. and it says "already
> connected to" database. While the query execution failed with "ORA-03114"
> and the httpd process is in CLOSE_WAIT state. How does it thinks it's
> already connected while it's actually not?
>
>
>- xinhuan
>
>
>
-
From: Perrin Harkins mailto:phark...@gmail.com>>
Date: Wednesday, November 6, 2013 5:54 PM
To: Xinhuan Zheng mailto:xzh...@christianbook.com>>
Cc: mod_perl list mailto:modperl@perl.apache.org>>
Subject: Re: Apache::DBI connect
On Wed, Nov 6, 2013 at
On Wed, Nov 6, 2013 at 4:07 PM, Xinhuan Zheng wrote:
> I wonder this line of code should be changed to 'DBI->connect(@args) if
> ($@)'. If ping failed, that means the connection is already closed, $drh
> may be no longer valid, will $drh->connect always return a valid new
> connection? What's the
rrin Harkins mailto:phark...@gmail.com>>
Date: Thursday, June 13, 2013 11:03 AM
To: Xinhuan Zheng mailto:xzh...@christianbook.com>>
Cc: "modperl@perl.apache.org<mailto:modperl@perl.apache.org>"
mailto:modperl@perl.apache.org>>
Subject: Re: Apache::DBI "connection lost co
: Fred Moyer
> Cc: Xinhuan Zheng , "modperl@perl.apache.org" <
> modperl@perl.apache.org>
>
> Subject: Re: Apache::DBI "connection lost contact" error
>
> Thanks Fred!
>
>
> On Wed, Jun 12, 2013 at 3:29 AM, Fred Moyer wrote:
>
>> Apac
y, June 12, 2013 5:53 AM
To: Fred Moyer mailto:f...@redhotpenguin.com>>
Cc: Xinhuan Zheng mailto:xzh...@christianbook.com>>,
"modperl@perl.apache.org<mailto:modperl@perl.apache.org>"
mailto:modperl@perl.apache.org>>
Subject: Re: Apache::DBI "connection lost co
I don't see the "connection lost
> contact"
> >> error anymore. The patch looks good to me.
> >>
> >> Thanks,
> >> - xinhuan
> >>
> >> From: Perrin Harkins
> >> Date: Thursday, June 6, 2013 3:02 PM
> >> To: Xinh
n
>>
>> From: Perrin Harkins
>> Date: Thursday, June 6, 2013 3:02 PM
>> To: Xinhuan Zheng
>> Cc: "modperl@perl.apache.org"
>>
>> Subject: Re: Apache::DBI "connection lost contact" error
>>
>> On Thu, Jun 6, 2013 at 12:22 PM, X
r anymore. The patch looks good to me.
>
> Thanks,
> - xinhuan
>
> From: Perrin Harkins
> Date: Thursday, June 6, 2013 3:02 PM
> To: Xinhuan Zheng
> Cc: "modperl@perl.apache.org"
>
> Subject: Re: Apache::DBI "connection lost contact" error
>
&g
hristianbook.com>>
Cc: "modperl@perl.apache.org<mailto:modperl@perl.apache.org>"
mailto:modperl@perl.apache.org>>
Subject: Re: Apache::DBI "connection lost contact" error
On Thu, Jun 6, 2013 at 12:22 PM, Xinhuan Zheng
mailto:xzh...@christianbook.com>>
On Thu, Jun 6, 2013 at 12:22 PM, Xinhuan Zheng
wrote:
> The database handle that is created in startup.pl needs to be really
disconnected (not overloaded disconnect) so that won't leave an idle server
> process running on the database side. Once it's really disconnected, the
server process can be
om>>
Cc: Jim Schueler mailto:jschue...@eloquency.com>>,
"modperl@perl.apache.org<mailto:modperl@perl.apache.org>"
mailto:modperl@perl.apache.org>>
Subject: Re: Apache::DBI "connection lost contact" error
On Tue, Jun 4, 2013 at 2:32 PM, Xinhuan Zheng
ma
On Tue, Jun 4, 2013 at 2:32 PM, Xinhuan Zheng
wrote:
> I have seen in other web servers when apachectl starts, there is no
"connect lost contact" error but it did happen when apachectl stops.
If your server does not receive constant requests, you may see this error
on shutdown because cached data
n
From: Perrin Harkins mailto:phark...@gmail.com>>
Date: Tuesday, June 4, 2013 12:18 PM
To: Xinhuan Zheng mailto:xzh...@christianbook.com>>
Cc: Jim Schueler mailto:jschue...@eloquency.com>>,
"modperl@perl.apache.org<mailto:modperl@perl.apache.org>"
mailto:m
On Tue, Jun 4, 2013 at 9:59 AM, Xinhuan Zheng
wrote:
> Will the new connection that's created be cached after then and the
connection that's not ping-able will be discarded?
Yes.
> Will this cached the new connection last until the child process exit?
Yes, unless it times out on the Oracle side
Hi Perrin,
> It looks to me like there's no danger here, just an annoying error message.
> Your connection from the parent process is being passed across the fork, but
> then when each child process tries to check it with ping() it fails and a new
> connection is opened to replace it.
It look
On Mon, Jun 3, 2013 at 4:36 PM, Dave Morgan wrote:
> As an administrator I still rely and depend on Apache::DBI, even if it is
unsupported.
Can we kill this rumor please? Apache::DBI is supported.
- Perrin
On Mon, Jun 3, 2013 at 2:36 PM, Dave Morgan wrote:
> On 06/03/2013 03:14 PM, Perrin Harkins wrote:
>
> DO NOT USE Apache::DBI with DBI::Connector or any other database caching
> technique. This requires
> knowledge of the code!!!
DBIx::Class monkey patches Apache::DBI so that the caching behavior
On 06/03/2013 03:14 PM, Perrin Harkins wrote:
On Monday, June 3, 2013, Xinhuan Zheng wrote:
> What is the check to see if the server is restarting? Is that new child
processes spawning?
I always found the best way to run/test Apache::DBI was to run a mod-perl
enabled http server without Apac
Hi Perrin,
> Does Apache::DBI work right with Apache2+mod_perl2?
Yes, but there may be a bug in how it checks to see if the server is restarting.
What is the check to see if the server is restarting? Is that new child
processes spawning?
If there is a bug in how it checks to see if the server
On Fri, May 31, 2013 at 5:45 PM, Xinhuan Zheng
wrote:
> 2520 Apache::DBI skipping connection during server startup,
read the docu !!
> 2520 Apache::DBI skipping connection during server startup,
read the docu !!
That's good.
> 2521 Apache::DBI push PerlChildEx
>>
Cc: Xinhuan Zheng mailto:xzh...@christianbook.com>>,
"modperl@perl.apache.org<mailto:modperl@perl.apache.org>"
mailto:modperl@perl.apache.org>>
Subject: Re: Apache::DBI "connection lost contact" error
$Apache::DBI::DEBUG = 2
> the perl web dev world is more splintered and there are fewer people
> on the mod_perl list than there used to be. That's a little sad for
> me to see, but the new stuff is pretty nice too, and lots of people
> are still using mod_perl and answering questions on this list.
>
I wonder if the
The mailing list has been the official place for support of all bundled
mod_perl modules for as long as I can remember. I don't think there's a
rule about perl core modules being passed between individuals either,
although I could be wrong. Sending people to a mailing list for support is
a common
I still use Alpine. And they never fixed the bug where ctrl-c (to cancel
a message) and ctrl-x (to send) are so easily confused. Oops. Maybe it's
time to start using a mouse.
Having wasted so much time, I'll try to be succinct:
Most modules on CPAN are bascially throwaways and not support
Hi Jim,
I appreciate the thought, but I'm not the mod_perl list. If you look at
who has done the most support around here recently, it's probably Torsten.
(Thanks Torsten!) More to the point, there are many people on the list
who know enough perl to help with a question about Apache::DBI. It's
Well, you are on the modperl list, so that means you. :)
Xinhuan, the error is harmless, but if you're concerned about it I would
try turning on debugging to make sure the connection is not being cached.
Do this:
$Apache::DBI::DEBUG = 2;
And then watch for a message like this in your log:
skippi
I'm afraid I'm out of my league. I just noticed the following comment on
the Apache::DBI man page:
Edmund Mergl was the original author of Apache::DBI. It is now supported
and maintained by the modperl mailinglist, see the mod_perl documentation
for instructions on how to subscribe.
-Ji
I believe I am using "my" declaration rather than "local". I also tried
explicitly disconnect but still have same issue. Since it only happens in
parent/child processes, I don't know a good way to debug parent/child, nor
reproducing the same error using a simple program. Can you guys help me
with t
Perrin is right. But fundamentally, I'd say that you're confusing
'local' and 'my' variable scoping:
http://www.perlmonks.org/?node_id=94007
-Jim
On Fri, 31 May 2013, Perrin Harkins wrote:
Try an explicit disconnect() call.
- Perrin
On Thu, May 30, 2013 at 7:46 PM, Xinhuan Zheng
wrot
Try an explicit disconnect() call.
- Perrin
On Thu, May 30, 2013 at 7:46 PM, Xinhuan Zheng wrote:
> The db handle is declared local and once it's out of scope, the destroy
> call will disconnect. But it appears even though variable is out of scope,
> we still get that error. Don't know why.
> -
The db handle is declared local and once it's out of scope, the destroy
call will disconnect. But it appears even though variable is out of scope,
we still get that error. Don't know why.
- xinhuan
On 5/30/13 8:31 AM, "Jim Schueler" wrote:
>Did this solve your problem?
>
> -Jim
>
>On Wed, 29 Ma
Did this solve your problem?
-Jim
On Wed, 29 May 2013, Perrin Harkins wrote:
Hi,
Apache::DBI is supposed to skip caching if you connect during startup. You
should just need to disconnect your database handle after you finish with
it. It sounds like you're opening it and then leaving it open
Hi,
Apache::DBI is supposed to skip caching if you connect during startup. You
should just need to disconnect your database handle after you finish with
it. It sounds like you're opening it and then leaving it open.
- Perrin
On Wed, May 29, 2013 at 3:24 PM, Xinhuan Zheng wrote:
> Hi,
>
> I
A few questions:
Precisely when do you get this error? When startup.pl exits or before?
Can you send a copy of your startup.pl file?
You get exactly the same error on startup and shutdown?
If PerlRequire startup.pl is commented out, do you still get errors?
Do you get errors when a
How about DBIx::Connector?
On Tue, Aug 2, 2011 at 6:30 AM, Feng He wrote:
> Hi,
>
> I just want to develop a modperl application.
> It's a handler, the database is Mysql.
> Shall I use Apache::DBI, or DBI is just fine ?
>
> Thank u.
> Regards.
>
--
Your clothes may be the latest in style but
On Wed, Aug 3, 2011 at 2:49 AM, Feng He wrote:
> ab -n 100 -c 3 http://bizstatus.game.yy.com/upload/?arguments
>
>
> When the client number is larger than one, the items number in
> database is not correct.
> it's always larger than 100, for example, 101, 102, 103 etc.
>
> So, what's wrong with my
On 8/3/2011 2:49 AM, Feng He wrote:
Hi,
Thank you all for the info.
I have finished writting the handler this morning, and have enabled
Apache::DBI in httpd.conf.
My handler is for this url:
http://bizstatus.game.yy.com/upload/
It accept client's uploaded data and write the data to database.
T
Hi,
Thank you all for the info.
I have finished writting the handler this morning, and have enabled
Apache::DBI in httpd.conf.
My handler is for this url:
http://bizstatus.game.yy.com/upload/
It accept client's uploaded data and write the data to database.
The strange stuff is, when I run more t
On Aug 2, 2011, at 6:30 AM, Feng He wrote:
> I just want to develop a modperl application.
> It's a handler, the database is Mysql.
> Shall I use Apache::DBI, or DBI is just fine ?
I recommend DBIx::Connector.
Best,
David
On Tuesday, 02 August 2011 15:30:28 Feng He wrote:
> I just want to develop a modperl application.
> It's a handler, the database is Mysql.
> Shall I use Apache::DBI, or DBI is just fine ?
It depends. Apache::DBI provides a transparent connection cache. You can
forget the DB handle acquired at so
On Jun 28, 2011, at 11:34 AM, Dave Morgan wrote:
> First off, please let me apologize for the tone of my last email,
> It was certainly not what I intended.
No worries. I assumed it was a caffeine shortage. That's what I suffer from
sometimes. :-)
> I have to stop having discussions about syste
Hi Randal,
>>>
>>> You lost me. But really, I strongly recommend against the use of
Apache::DBI. Some discussion here:
>>>
>>>
http://search.cpan.org/dist/DBIx-Connector/lib/DBIx/Connector.pm#Description
>>>
>
>Dave> And having read that, I strongly recommend against the use of
DBIx-Conne
> "Dave" == Dave Morgan writes:
>>
>> You lost me. But really, I strongly recommend against the use of
>> Apache::DBI. Some discussion here:
>>
>> http://search.cpan.org/dist/DBIx-Connector/lib/DBIx/Connector.pm#Description
>>
Dave> And having read that, I strongly recommend against the
First off, please let me apologize for the tone of my last email,
It was certainly not what I intended.
I have to stop having discussions about system design and
philosophy after having meetings with a developer who's most
intelligent statement was "It works on my machine". Cold Fusion not
mod-pe
On Jun 27, 2011, at 4:20 PM, Dave Morgan wrote:
> What's the point of it?
First of all, what Perrin said. :-)
> As far as I can see the author claims to have issues with Apache::DBI and
> does not
> like the hidden aspect.
FWIW, I am the author.
> I have never experienced his "issues" and the
Please calm down, folks.
Apache::DBI is a module that was designed to help with porting legacy
CGI applications to mod_perl. It's a valid criticism to say that the
action-at-a-distance parts of it are undesirable in new mod_perl
applications. Personally, I have used mostly custom caching code
in
On 27/06/11 04:27 PM, David E. Wheeler wrote:
On Jun 27, 2011, at 1:40 PM, Dave Morgan wrote:
You lost me. But really, I strongly recommend against the use of Apache::DBI.
Some discussion here:
http://search.cpan.org/dist/DBIx-Connector/lib/DBIx/Connector.pm#Description
And having read
On Jun 27, 2011, at 2:17 PM, Fred Moyer wrote:
>> You lost me. But really, I strongly recommend against the use of
>> Apache::DBI. Some discussion here:
>> http://search.cpan.org/dist/DBIx-Connector/lib/DBIx/Connector.pm#Description
>
> It seems like you are looking for a more feature rich db c
On Jun 27, 2011, at 1:40 PM, Dave Morgan wrote:
>> You lost me. But really, I strongly recommend against the use of
>> Apache::DBI. Some discussion here:
>>
>>
>> http://search.cpan.org/dist/DBIx-Connector/lib/DBIx/Connector.pm#Description
>>
>
> And having read that, I strongly recommend a
On Mon, Jun 27, 2011 at 1:22 PM, David E. Wheeler wrote:
> On Jun 27, 2011, at 1:13 PM, Fred Moyer wrote:
>
>> Wow, that's obnoxious:
>>
>> 1237 if ($INC{'Apache/DBI.pm'} && $ENV{MOD_PERL}) {
>> 1238 $old_connect_via = $DBI::connect_via;
>> 1239 $DBI::connect_via = 'connect';
>> 1240 }
On 27/06/11 02:22 PM, David E. Wheeler wrote:
On Jun 27, 2011, at 1:13 PM, Fred Moyer wrote:
Snip .
You lost me. But really, I strongly recommend against the use of Apache::DBI.
Some discussion here:
http://search.cpan.org/dist/DBIx-Connector/lib/DBIx/Connector.pm#Description
And
On Jun 27, 2011, at 1:13 PM, Fred Moyer wrote:
> Wow, that's obnoxious:
>
> 1237 if ($INC{'Apache/DBI.pm'} && $ENV{MOD_PERL}) {
> 1238 $old_connect_via = $DBI::connect_via;
> 1239 $DBI::connect_via = 'connect';
> 1240 }
DBIx::Connector does the same thing.
> And it is also apparentl
Hi Richard,
> In Apache::DBI 1.06 $r is not used but $s is used. And no such
> seg faults occur. Any one know what is the rational for this change?
Yes. It didn't work in Apache::DBI 1.06. Attaching a cleanup handler
to $s does not run that handler at the end of the current request,
whic
There was this recent thread which may be helpful - I didn't follow it
that closely:
http://www.gossamer-threads.com/lists/modperl/modperl/102636
On Wed, Mar 2, 2011 at 8:10 AM, Richard Chen wrote:
> Hi,
>
> In order to make use of the ChildExitHandler introduced
> in Apache::DBI 1.09, w
On Thu, 24 Feb 2011 03:28:19 +1100, Daniel Manley
wrote:
I've been digging around in my mod_perl-based apps and trying to figure
out why setting up the DB connections for pinging is still randomly
producing first-thing-in-the-morning "mysql server has gone away"
errors. I read up about
On Wed, Feb 23, 2011 at 4:07 PM, Daniel Manley wrote:
> well, I think I figured this one out on my own. Though I've used Perl for a
> number of years, I've never gotten to the XS file coding. and so after
> running this under perl debug, I finally get the hint that maybe the mysql
> ping() is do
well, I think I figured this one out on my own. Though I've used Perl
for a number of years, I've never gotten to the XS file coding. and so
after running this under perl debug, I finally get the hint that maybe
the mysql ping() is done in C. And so it is.
Dan
On 11-02-23 11:28 AM, Daniel
On Sat, Apr 17, 2010 at 4:42 PM, Chris Bennett
wrote:
> You may also have other connections, but these will reconnect-disconnect
> each time
For the record, Apache::DBI will work with any number of connections,
keeping them persistent. It's also correct to call connect_on_init
multiple times. I
On 17.4.2010 23:21, Jiri Pavlovsky wrote:
On 17.4.2010 22:42, Chris Bennett wrote:
Oh, this is your error. You may only use Apache::DBI_connect_on_init for
ONE connection, which stays up and running. Use your more important one
(for speed) for this.
This doesn't seem to make difference. It
On 17.4.2010 22:42, Chris Bennett wrote:
Oh, this is your error. You may only use Apache::DBI_connect_on_init for
ONE connection, which stays up and running. Use your more important one
(for speed) for this.
This doesn't seem to make difference. It doesn't work even when making
only one con
On 04/17/10 15:09, Jiri Pavlovsky wrote:
On 17.4.2010 22:22, Chris Bennett wrote:
On 04/17/10 14:27, Jiri Pavlovsky wrote:
Hello,
I'm trying to prestart db connection. But Apache::DBI->connect_on_init
is not working. Gives no error, but db connection is not made.
Setting $Apache::DBI::DEBUG =
On Sat, Apr 17, 2010 at 1:09 PM, Jiri Pavlovsky
wrote:> Apache::DBI->connect_on_init("dbi:Pg:dbname=p69",
> "user",
> "pass",
> {
> PrintError => 1, # warn() on errors
> RaiseError => 0, # don't die on error
> AutoCommit => 1, # commit executes immediately
> pg_enable
On 17.4.2010 22:22, Chris Bennett wrote:
On 04/17/10 14:27, Jiri Pavlovsky wrote:
Hello,
I'm trying to prestart db connection. But Apache::DBI->connect_on_init
is not working. Gives no error, but db connection is not made.
Setting $Apache::DBI::DEBUG = 2 indicates that ChildInitHandler runs.
I
On 04/17/10 14:27, Jiri Pavlovsky wrote:
Hello,
I'm trying to prestart db connection. But Apache::DBI->connect_on_init
is not working. Gives no error, but db connection is not made.
Setting $Apache::DBI::DEBUG = 2 indicates that ChildInitHandler runs.
I tried to create my custom ChildInitHandle
R P wrote:
I thought I read another bug report that said it was fixed. 1.06
worked, but now every request gets:
/libexec/ld-elf.so.1:
/usr/local/lib/perl5/site_perl/5.8.8/mach/auto/APR/Request/Apache2/Apache2.so:
Undefined symbol "apreq_handle_apache2"
This is unrelated, you need to add
1 - 100 of 361 matches
Mail list logo
