perl-modperl mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Xinhuan Zheng <xzh...@christianbook.com>
Subject Re: Apache::DBI connect
Date Fri, 08 Nov 2013 04:06:52 GMT
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. It almost looked like
the query is executing on a completely different database handle. Sometimes the query can
succeed but sometimes the query would fail. We use Apache::DBI and DBI and use Apache::DBI
is before DBI. We actually call DBI->connect_cached and based on DBI document, I guess
this would be handled by Apache::DBI connect. However, I guess we also defined a base class
that can store a database handle. There are subclasses inherited from this base class. Is
that good idea to store a database handle in a base class?

- xinhuan

From: Perrin Harkins <pharkins@gmail.com<mailto:pharkins@gmail.com>>
Date: Thursday, November 7, 2013 8:08 PM
To: Xinhuan Zheng <xzheng@christianbook.com<mailto:xzheng@christianbook.com>>
Cc: Adam Prime <adam.prime@utoronto.ca<mailto:adam.prime@utoronto.ca>>, "modperl@perl.apache.org<mailto:modperl@perl.apache.org>"
<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 are sometimes called "short circuit" operators because of this.

- Perrin


On Thu, Nov 7, 2013 at 4:18 PM, Xinhuan Zheng <xzheng@christianbook.com<mailto:xzheng@christianbook.com>>
wrote:
That's fine. I can do more debugging.

But I have hard time to understand this line of code:

200     if ($Connected{$Idx} and (!$needping or eval{$Connected{$Idx}->ping})) {

Should this be:

200     if ($Connected{$Idx} and ($needping and eval{$Connected{$Idx}->ping})) {

What's the difference between the two? Why the code in favor of "or" instead of "and"?

- xinhuan

From: Perrin Harkins <pharkins@gmail.com<mailto:pharkins@gmail.com>>
Date: Thursday, November 7, 2013 3:05 PM

To: Xinhuan Zheng <xzheng@christianbook.com<mailto:xzheng@christianbook.com>>
Cc: Adam Prime <adam.prime@utoronto.ca<mailto:adam.prime@utoronto.ca>>, "modperl@perl.apache.org<mailto:modperl@perl.apache.org>"
<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 debugging print statements to figure out where it's having trouble.  All I can
say from that output is that it it's not succeeding in making a new connection after the ping
fails, because it doesn't say "new connect..." after that.  I also wonder where that disconnect()
call is coming from.

- Perrin


On Thu, Nov 7, 2013 at 1:07 PM, Xinhuan Zheng <xzheng@christianbook.com<mailto:xzheng@christianbook.com>>
wrote:
I only looked at Apache::DBI not DBI document.

My test program works. It reconnects to database OK. I ran it multiple times and every time
it reconnects OK. But Apache::DBI doesn't work. You saw the previous debugging info. Where
is the problem?

- xinhuan

From: Perrin Harkins <pharkins@gmail.com<mailto:pharkins@gmail.com>>
Date: Thursday, November 7, 2013 1:00 PM
To: Xinhuan Zheng <xzheng@christianbook.com<mailto:xzheng@christianbook.com>>
Cc: Adam Prime <adam.prime@utoronto.ca<mailto:adam.prime@utoronto.ca>>, "modperl@perl.apache.org<mailto:modperl@perl.apache.org>"
<modperl@perl.apache.org<mailto: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 Zheng <xzheng@christianbook.com<mailto:xzheng@christianbook.com>>
wrote:
So it returns string '0E0'? The document didn't say that.

- xinhuan

On 11/7/13 11:44 AM, "Adam Prime" <adam.prime@utoronto.ca<mailto:adam.prime@utoronto.ca>>
wrote:

>perl -e "if ('0E0') { print qq[hi\n] }"
>hi
>
>OE0 as a string evaluates to true.  If you use it as a bareword /
>numeric then it's false, which is what your eval example below is doing.
>
>Adam
>
>
>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 <xzheng@christianbook.com<mailto:xzheng@christianbook.com>
>> <mailto:xzheng@christianbook.com<mailto:xzheng@christianbook.com>>>
>> Date: Thursday, November 7, 2013 11:12 AM
>> To: Perrin Harkins <pharkins@gmail.com<mailto:pharkins@gmail.com> <mailto:pharkins@gmail.com<mailto:pharkins@gmail.com>>>
>> Cc: mod_perl list <modperl@perl.apache.org<mailto:modperl@perl.apache.org>
>><mailto:modperl@perl.apache.org<mailto:modperl@perl.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
>> "zero but true" and undef. I don't know. ora_ping() is foreign to me. I
>> made the change based on what Apache::DBI the document said.
>>
>>> In any case, there's no need to change the Apache::DBI code, even with
>>>your "select 1 from dual" test.   It returns a true value (0E0) if it
>>>succeeds and a false value (undef) if it fails.
>>
>> In both cases, the return value is evaluated to true:
>>
>> 200: if ($Connected{$Idx} and (!$needping or
>>eval{$Connected{$Idx}->ping}))
>>
>> eval{0E0} and eval{undef} both return true. I did test that. How do you
>> distinguish?
>>
>>> Did your script succeed in reconnecting after it lost the connection?
>>
>> Yes.
>>
>>> Yes, I haven't forgotten about that, but I haven't had time to work on
>>>it yet.  You can try fixing it yourself by looking at the code in
>>>Apache::DBI that checks if the server is starting under apache 1.x.
>>>Otherwise, I will eventually get to it.
>>
>> I don't understand that piece of code. I can't do the change. Hope you
>> can help.
>>
>> - xinhuan
>>
>> From: Perrin Harkins <pharkins@gmail.com<mailto:pharkins@gmail.com> <mailto:pharkins@gmail.com<mailto:pharkins@gmail.com>>>
>> Date: Thursday, November 7, 2013 11:00 AM
>> To: Xinhuan Zheng <xzheng@christianbook.com<mailto:xzheng@christianbook.com>
>> <mailto:xzheng@christianbook.com<mailto:xzheng@christianbook.com>>>
>> Cc: mod_perl list <modperl@perl.apache.org<mailto: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 9:46 AM, Xinhuan Zheng <xzheng@christianbook.com<mailto:xzheng@christianbook.com>
>> <mailto:xzheng@christianbook.com<mailto:xzheng@christianbook.com>>>
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.
>>
>>> Since I changed DBD::Oracle subroutine ping to use 'select 1 from
>>>dual',
>>
>> I don't actually understand why you did that.  What was wrong with the
>> normal ping?
>>
>> In any case, there's no need to change the Apache::DBI code, even with
>> your "select 1 from dual" test.  It returns a true value (0E0) if it
>> succeeds and a false value (undef) if it fails.
>>
>> Did your script succeed in reconnecting after it lost the connection?
>>
>>> I have another request. The Apache::DBI cached a dead database handle
>>>for apache version 1.3.42 if  startup.pl<http://startup.pl> <http://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 good. Can you please identify and change the code for this
>> problem?
>>
>> Yes, I haven't forgotten about that, but I haven't had time to work on
>> it yet.  You can try fixing it yourself by looking at the code in
>> Apache::DBI that checks if the server is starting under apache 1.x.
>>   Otherwise, I will eventually get to it.
>>
>> - Perrin
>>
>





Mime
View raw message