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 <xzh...@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 <phark...@gmail.com>
> Date: Thursday, November 7, 2013 3:05 PM
>
> To: Xinhuan Zheng <xzh...@christianbook.com>
> Cc: Adam Prime <adam.pr...@utoronto.ca>, "modperl@perl.apache.org" <
> 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 <xzh...@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 <phark...@gmail.com>
>> Date: Thursday, November 7, 2013 1:00 PM
>> To: Xinhuan Zheng <xzh...@christianbook.com>
>> Cc: Adam Prime <adam.pr...@utoronto.ca>, "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 Zheng
>> <xzh...@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.pr...@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 <xzh...@christianbook.com
>>> >> <mailto:xzh...@christianbook.com>>
>>> >> Date: Thursday, November 7, 2013 11:12 AM
>>> >> To: Perrin Harkins <phark...@gmail.com <mailto:phark...@gmail.com>>
>>> >> Cc: mod_perl list <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 <phark...@gmail.com <mailto:phark...@gmail.com>>
>>> >> Date: Thursday, November 7, 2013 11:00 AM
>>> >> To: Xinhuan Zheng <xzh...@christianbook.com
>>> >> <mailto:xzh...@christianbook.com>>
>>> >> Cc: mod_perl list <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 <
>>> xzh...@christianbook.com
>>> >> <mailto:xzh...@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> 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
>>> >>
>>> >
>>>
>>>
>>
>
