You are viewing a plain text version of this content. The canonical link for it is here.
Posted to modperl@perl.apache.org by Xinhuan Zheng <xz...@christianbook.com> on 2013/11/06 22:07:27 UTC
Apache::DBI connect
Hi,
I am using Apache+mod_perl and Apache::DBI with Oracle connection pooling feature. I noticed a problem with subroutine connect. Below code checks database connection:
200: if ($Connected{$Idx} and (!$needping or eval{$Connected{$Idx}->ping})) {
debug(2, "$prefix already connected to '$Idx'");
# Force clean up of handle in case previous transaction failed to
# clean up the handle
&reset_startup_state($Idx);
return (bless $Connected{$Idx}, 'Apache::DBI::db');
}
Due to the oracle connection pooling, some oracle server processes has terminated the connection, causing httpd process in CLOSE_WAIT state. I did get this message in error_log when eval{$Connected{$Idx}->ping failed:
DBD::Oracle::db ping failed: ORA-03113: end-of-file on communication channel
Process ID: 28345
Session ID: 3220 Serial number: 504 (DBD ERROR: OCIStmtExecute/Describe) at /usr/local/lib/perl5/site_perl/5.8.3/Apache/DBI.pm line 200
Below is subsequent code:
213 delete $Connected{$Idx};
214 $Connected{$Idx} = $drh->connect(@args);
215 return undef if !$Connected{$Idx};
After line 214 executes, it doesn't establish a valid new connection. The httpd process is still in CLOSE_WAIT state.
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 difference between DBI->connect vs $drh->connect?
Thanks,
- xinhuan
Re: Apache::DBI connect
Posted by Xinhuan Zheng <xz...@christianbook.com>.
Hi Perrin,
Thanks very much for below information. This is helpful. My conclusion is that there is no problem in Apache::DBI. It is the application code that doesn't handle db connection correctly.
- xinhuan
From: Perrin Harkins <ph...@gmail.com>>
Date: Monday, November 11, 2013 9:57 AM
To: Xinhuan Zheng <xz...@christianbook.com>>
Cc: Adam Prime <ad...@utoronto.ca>>, "modperl@perl.apache.org<ma...@perl.apache.org>" <mo...@perl.apache.org>>
Subject: Re: Apache::DBI connect
On Fri, Nov 8, 2013 at 2:58 PM, Xinhuan Zheng <xz...@christianbook.com>> 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 finds a cached connection and ping is ok but sometimes from the same process it didn't find a cached connection. Since it's the same process, it doesn't make sense it can find a cached one then it didn't find any. Even after it says it didn't find a cached one then after that it prints out it still has a cached one and can use that one. It sounds like in same process sometimes the Apache:DBI connection cache can be accessed but sometimes it cannot.
The cache can always be accessed. It's just a hash in a global variable. There are a couple of possible explanations for what you're seeing, off the top of my head. One is that you might be sending in slightly different connection parameters, which means you can't use the cached connection. Another is that your code might not be calling DBI->connect() or DBI->connect_cached().
The base class is similar to a class in Java world. Basically it has set and get methods. Among other things, it sets $db and gets $db. The class has its own fetch method and it'll use $self->db method call to do the fetch/insert,etc.
It's ok to keep a database handle during the length of one request, but you shouldn't keep it in your own global between requests, so if objects of this class stay around for longer than one request you should not store a db handle in them. The safest thing would be for your $self->db() method to just call DBI->connect_cached() every time.
BTW, the class has a method AUTOLOAD, although I don't quite understand how AUTOLOAD works.
There's a lot of good documentation on AUTOLOAD in the Perl man pages and books. It's not relevant to your database issues though.
- Perrin
Re: Apache::DBI connect
Posted by Perrin Harkins <ph...@gmail.com>.
On Fri, Nov 8, 2013 at 2:58 PM, Xinhuan Zheng <xz...@christianbook.com>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 finds a cached connection and ping is ok
> but sometimes from the same process it didn't find a cached connection.
> Since it's the same process, it doesn't make sense it can find a cached one
> then it didn't find any. Even after it says it didn't find a cached one
> then after that it prints out it still has a cached one and can use that
> one. It sounds like in same process sometimes the Apache:DBI connection
> cache can be accessed but sometimes it cannot.
>
The cache can always be accessed. It's just a hash in a global variable.
There are a couple of possible explanations for what you're seeing, off
the top of my head. One is that you might be sending in slightly different
connection parameters, which means you can't use the cached connection.
Another is that your code might not be calling DBI->connect() or
DBI->connect_cached().
> The base class is similar to a class in Java world. Basically it has set
> and get methods. Among other things, it sets $db and gets $db. The class
> has its own fetch method and it'll use $self->db method call to do the
> fetch/insert,etc.
>
It's ok to keep a database handle during the length of one request, but you
shouldn't keep it in your own global between requests, so if objects of
this class stay around for longer than one request you should not store a
db handle in them. The safest thing would be for your $self->db() method
to just call DBI->connect_cached() every time.
> BTW, the class has a method AUTOLOAD, although I don't quite understand
> how AUTOLOAD works.
>
There's a lot of good documentation on AUTOLOAD in the Perl man pages and
books. It's not relevant to your database issues though.
- Perrin
Re: Apache::DBI connect
Posted by Xinhuan Zheng <xz...@christianbook.com>.
Hi Perrin,
The query is from the application code not the 'select 1' test query.
While most of time I saw Apache::DBI->connect is called but sometime from a process, it will print out it finds a cached connection and ping is ok but sometimes from the same process it didn't find a cached connection. Since it's the same process, it doesn't make sense it can find a cached one then it didn't find any. Even after it says it didn't find a cached one then after that it prints out it still has a cached one and can use that one. It sounds like in same process sometimes the Apache:DBI connection cache can be accessed but sometimes it cannot.
The base class is similar to a class in Java world. Basically it has set and get methods. Among other things, it sets $db and gets $db. The class has its own fetch method and it'll use $self->db method call to do the fetch/insert,etc. BTW, the class has a method AUTOLOAD, although I don't quite understand how AUTOLOAD works. The document says the method call will be magically come to exist with AUTOLOAD. If this is not desirable, then should we get rid of $db completely from the base class? Then every time it needs fetch/insert,etc, call DBI->connect_cached instead since that way Apache::DBI->connect will be called and the connection can be validated?
- xinhuan
From: Perrin Harkins <ph...@gmail.com>>
Date: Friday, November 8, 2013 10:41 AM
To: Xinhuan Zheng <xz...@christianbook.com>>
Cc: Adam Prime <ad...@utoronto.ca>>, "modperl@perl.apache.org<ma...@perl.apache.org>" <mo...@perl.apache.org>>
Subject: Re: Apache::DBI connect
On Thu, Nov 7, 2013 at 11:06 PM, Xinhuan Zheng <xz...@christianbook.com>> 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 something else in your own code?
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.
Yes, it should be.
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?
No, don't do that. You should pick one approach for managing database handles, whether it's Apache::DBI or something else, and only use that. If you keep a database handle around in a global somewhere, it may time out and nothing will ping it because you're not calling connect() on each request.
- Perrin
Re: Apache::DBI connect
Posted by Perrin Harkins <ph...@gmail.com>.
On Thu, Nov 7, 2013 at 11:06 PM, Xinhuan Zheng <xz...@christianbook.com>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 something
else in your own code?
> 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.
Yes, it should be.
> 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?
No, don't do that. You should pick one approach for managing database
handles, whether it's Apache::DBI or something else, and only use that. If
you keep a database handle around in a global somewhere, it may time out
and nothing will ping it because you're not calling connect() on each
request.
- Perrin
Re: Apache::DBI connect
Posted by Xinhuan Zheng <xz...@christianbook.com>.
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 <ph...@gmail.com>>
Date: Thursday, November 7, 2013 8:08 PM
To: Xinhuan Zheng <xz...@christianbook.com>>
Cc: Adam Prime <ad...@utoronto.ca>>, "modperl@perl.apache.org<ma...@perl.apache.org>" <mo...@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 <xz...@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 <ph...@gmail.com>>
Date: Thursday, November 7, 2013 3:05 PM
To: Xinhuan Zheng <xz...@christianbook.com>>
Cc: Adam Prime <ad...@utoronto.ca>>, "modperl@perl.apache.org<ma...@perl.apache.org>" <mo...@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 <xz...@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 <ph...@gmail.com>>
Date: Thursday, November 7, 2013 1:00 PM
To: Xinhuan Zheng <xz...@christianbook.com>>
Cc: Adam Prime <ad...@utoronto.ca>>, "modperl@perl.apache.org<ma...@perl.apache.org>" <mo...@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 <xz...@christianbook.com>> wrote:
So it returns string '0E0'? The document didn't say that.
- xinhuan
On 11/7/13 11:44 AM, "Adam Prime" <ad...@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 <xz...@christianbook.com>
>> <ma...@christianbook.com>>>
>> Date: Thursday, November 7, 2013 11:12 AM
>> To: Perrin Harkins <ph...@gmail.com> <ma...@gmail.com>>>
>> Cc: mod_perl list <mo...@perl.apache.org>
>><ma...@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 <ph...@gmail.com> <ma...@gmail.com>>>
>> Date: Thursday, November 7, 2013 11:00 AM
>> To: Xinhuan Zheng <xz...@christianbook.com>
>> <ma...@christianbook.com>>>
>> Cc: mod_perl list <mo...@perl.apache.org>
>><ma...@perl.apache.org>>>
>> Subject: Re: Apache::DBI connect
>>
>> On Thu, Nov 7, 2013 at 9:46 AM, Xinhuan Zheng <xz...@christianbook.com>
>> <ma...@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
>>
>
Re: Apache::DBI connect
Posted by Perrin Harkins <ph...@gmail.com>.
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 <xz...@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 <ph...@gmail.com>
> Date: Thursday, November 7, 2013 3:05 PM
>
> To: Xinhuan Zheng <xz...@christianbook.com>
> Cc: Adam Prime <ad...@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 <xz...@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 <ph...@gmail.com>
>> Date: Thursday, November 7, 2013 1:00 PM
>> To: Xinhuan Zheng <xz...@christianbook.com>
>> Cc: Adam Prime <ad...@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 <xz...@christianbook.com>wrote:
>>
>>> So it returns string '0E0'? The document didn't say that.
>>>
>>> - xinhuan
>>>
>>> On 11/7/13 11:44 AM, "Adam Prime" <ad...@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
>>> >> <ma...@christianbook.com>>
>>> >> Date: Thursday, November 7, 2013 11:12 AM
>>> >> To: Perrin Harkins <pharkins@gmail.com <ma...@gmail.com>>
>>> >> Cc: mod_perl list <modperl@perl.apache.org
>>> >><ma...@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 <ma...@gmail.com>>
>>> >> Date: Thursday, November 7, 2013 11:00 AM
>>> >> To: Xinhuan Zheng <xzheng@christianbook.com
>>> >> <ma...@christianbook.com>>
>>> >> Cc: mod_perl list <modperl@perl.apache.org
>>> >><ma...@perl.apache.org>>
>>> >> Subject: Re: Apache::DBI connect
>>> >>
>>> >> On Thu, Nov 7, 2013 at 9:46 AM, Xinhuan Zheng <
>>> xzheng@christianbook.com
>>> >> <ma...@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
>>> >>
>>> >
>>>
>>>
>>
>
Re: Apache::DBI connect
Posted by Xinhuan Zheng <xz...@christianbook.com>.
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 <ph...@gmail.com>>
Date: Thursday, November 7, 2013 3:05 PM
To: Xinhuan Zheng <xz...@christianbook.com>>
Cc: Adam Prime <ad...@utoronto.ca>>, "modperl@perl.apache.org<ma...@perl.apache.org>" <mo...@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 <xz...@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 <ph...@gmail.com>>
Date: Thursday, November 7, 2013 1:00 PM
To: Xinhuan Zheng <xz...@christianbook.com>>
Cc: Adam Prime <ad...@utoronto.ca>>, "modperl@perl.apache.org<ma...@perl.apache.org>" <mo...@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 <xz...@christianbook.com>> wrote:
So it returns string '0E0'? The document didn't say that.
- xinhuan
On 11/7/13 11:44 AM, "Adam Prime" <ad...@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 <xz...@christianbook.com>
>> <ma...@christianbook.com>>>
>> Date: Thursday, November 7, 2013 11:12 AM
>> To: Perrin Harkins <ph...@gmail.com> <ma...@gmail.com>>>
>> Cc: mod_perl list <mo...@perl.apache.org>
>><ma...@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 <ph...@gmail.com> <ma...@gmail.com>>>
>> Date: Thursday, November 7, 2013 11:00 AM
>> To: Xinhuan Zheng <xz...@christianbook.com>
>> <ma...@christianbook.com>>>
>> Cc: mod_perl list <mo...@perl.apache.org>
>><ma...@perl.apache.org>>>
>> Subject: Re: Apache::DBI connect
>>
>> On Thu, Nov 7, 2013 at 9:46 AM, Xinhuan Zheng <xz...@christianbook.com>
>> <ma...@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
>>
>
Re: Apache::DBI connect
Posted by Perrin Harkins <ph...@gmail.com>.
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 <xz...@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 <ph...@gmail.com>
> Date: Thursday, November 7, 2013 1:00 PM
> To: Xinhuan Zheng <xz...@christianbook.com>
> Cc: Adam Prime <ad...@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 <xz...@christianbook.com>wrote:
>
>> So it returns string '0E0'? The document didn't say that.
>>
>> - xinhuan
>>
>> On 11/7/13 11:44 AM, "Adam Prime" <ad...@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
>> >> <ma...@christianbook.com>>
>> >> Date: Thursday, November 7, 2013 11:12 AM
>> >> To: Perrin Harkins <pharkins@gmail.com <ma...@gmail.com>>
>> >> Cc: mod_perl list <modperl@perl.apache.org
>> >><ma...@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 <ma...@gmail.com>>
>> >> Date: Thursday, November 7, 2013 11:00 AM
>> >> To: Xinhuan Zheng <xzheng@christianbook.com
>> >> <ma...@christianbook.com>>
>> >> Cc: mod_perl list <modperl@perl.apache.org
>> >><ma...@perl.apache.org>>
>> >> Subject: Re: Apache::DBI connect
>> >>
>> >> On Thu, Nov 7, 2013 at 9:46 AM, Xinhuan Zheng <
>> xzheng@christianbook.com
>> >> <ma...@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
>> >>
>> >
>>
>>
>
Re: Apache::DBI connect
Posted by Xinhuan Zheng <xz...@christianbook.com>.
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 <ph...@gmail.com>>
Date: Thursday, November 7, 2013 1:00 PM
To: Xinhuan Zheng <xz...@christianbook.com>>
Cc: Adam Prime <ad...@utoronto.ca>>, "modperl@perl.apache.org<ma...@perl.apache.org>" <mo...@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 <xz...@christianbook.com>> wrote:
So it returns string '0E0'? The document didn't say that.
- xinhuan
On 11/7/13 11:44 AM, "Adam Prime" <ad...@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 <xz...@christianbook.com>
>> <ma...@christianbook.com>>>
>> Date: Thursday, November 7, 2013 11:12 AM
>> To: Perrin Harkins <ph...@gmail.com> <ma...@gmail.com>>>
>> Cc: mod_perl list <mo...@perl.apache.org>
>><ma...@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 <ph...@gmail.com> <ma...@gmail.com>>>
>> Date: Thursday, November 7, 2013 11:00 AM
>> To: Xinhuan Zheng <xz...@christianbook.com>
>> <ma...@christianbook.com>>>
>> Cc: mod_perl list <mo...@perl.apache.org>
>><ma...@perl.apache.org>>>
>> Subject: Re: Apache::DBI connect
>>
>> On Thu, Nov 7, 2013 at 9:46 AM, Xinhuan Zheng <xz...@christianbook.com>
>> <ma...@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
>>
>
Re: Apache::DBI connect
Posted by Perrin Harkins <ph...@gmail.com>.
It is in the DBI documentation. Search for "0E0".
- Perrin
On Thu, Nov 7, 2013 at 12:41 PM, Xinhuan Zheng <xz...@christianbook.com>wrote:
> So it returns string '0E0'? The document didn't say that.
>
> - xinhuan
>
> On 11/7/13 11:44 AM, "Adam Prime" <ad...@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
> >> <ma...@christianbook.com>>
> >> Date: Thursday, November 7, 2013 11:12 AM
> >> To: Perrin Harkins <pharkins@gmail.com <ma...@gmail.com>>
> >> Cc: mod_perl list <modperl@perl.apache.org
> >><ma...@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 <ma...@gmail.com>>
> >> Date: Thursday, November 7, 2013 11:00 AM
> >> To: Xinhuan Zheng <xzheng@christianbook.com
> >> <ma...@christianbook.com>>
> >> Cc: mod_perl list <modperl@perl.apache.org
> >><ma...@perl.apache.org>>
> >> Subject: Re: Apache::DBI connect
> >>
> >> On Thu, Nov 7, 2013 at 9:46 AM, Xinhuan Zheng <xzheng@christianbook.com
> >> <ma...@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
> >>
> >
>
>
Re: Apache::DBI connect
Posted by Xinhuan Zheng <xz...@christianbook.com>.
So it returns string '0E0'? The document didn't say that.
- xinhuan
On 11/7/13 11:44 AM, "Adam Prime" <ad...@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
>> <ma...@christianbook.com>>
>> Date: Thursday, November 7, 2013 11:12 AM
>> To: Perrin Harkins <pharkins@gmail.com <ma...@gmail.com>>
>> Cc: mod_perl list <modperl@perl.apache.org
>><ma...@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 <ma...@gmail.com>>
>> Date: Thursday, November 7, 2013 11:00 AM
>> To: Xinhuan Zheng <xzheng@christianbook.com
>> <ma...@christianbook.com>>
>> Cc: mod_perl list <modperl@perl.apache.org
>><ma...@perl.apache.org>>
>> Subject: Re: Apache::DBI connect
>>
>> On Thu, Nov 7, 2013 at 9:46 AM, Xinhuan Zheng <xzheng@christianbook.com
>> <ma...@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
>>
>
Re: Apache::DBI connect
Posted by Adam Prime <ad...@utoronto.ca>.
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
> <ma...@christianbook.com>>
> Date: Thursday, November 7, 2013 11:12 AM
> To: Perrin Harkins <pharkins@gmail.com <ma...@gmail.com>>
> Cc: mod_perl list <modperl@perl.apache.org <ma...@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 <ma...@gmail.com>>
> Date: Thursday, November 7, 2013 11:00 AM
> To: Xinhuan Zheng <xzheng@christianbook.com
> <ma...@christianbook.com>>
> Cc: mod_perl list <modperl@perl.apache.org <ma...@perl.apache.org>>
> Subject: Re: Apache::DBI connect
>
> On Thu, Nov 7, 2013 at 9:46 AM, Xinhuan Zheng <xzheng@christianbook.com
> <ma...@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
>
Re: Apache::DBI connect
Posted by Xinhuan Zheng <xz...@christianbook.com>.
one correct - In both cases, the return value is evaluated to false.
How do you distinguish?
- xinhuan
From: Xinhuan Zheng <xz...@christianbook.com>>
Date: Thursday, November 7, 2013 11:12 AM
To: Perrin Harkins <ph...@gmail.com>>
Cc: mod_perl list <mo...@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 <ph...@gmail.com>>
Date: Thursday, November 7, 2013 11:00 AM
To: Xinhuan Zheng <xz...@christianbook.com>>
Cc: mod_perl list <mo...@perl.apache.org>>
Subject: Re: Apache::DBI connect
On Thu, Nov 7, 2013 at 9:46 AM, Xinhuan Zheng <xz...@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
Re: Apache::DBI connect
Posted by Xinhuan Zheng <xz...@christianbook.com>.
> 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 <ph...@gmail.com>>
Date: Thursday, November 7, 2013 11:00 AM
To: Xinhuan Zheng <xz...@christianbook.com>>
Cc: mod_perl list <mo...@perl.apache.org>>
Subject: Re: Apache::DBI connect
On Thu, Nov 7, 2013 at 9:46 AM, Xinhuan Zheng <xz...@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
Re: Apache::DBI connect
Posted by Perrin Harkins <ph...@gmail.com>.
On Thu, Nov 7, 2013 at 9:46 AM, Xinhuan Zheng <xz...@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 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
Re: Apache::DBI connect
Posted by Xinhuan Zheng <xz...@christianbook.com>.
Hi Perrin,
The DRCP settings is configured as the document expects.
I made a simple script outside mod_perl and use DBI to test re-connect to Oracle. The test shows where the problem is.
#!/usr/local/bin/perl
use DBI;
print "first connect\n";
$dbh = DBI->connect('dbi:Oracle:','...','...');
print "first select\n";
$ok = $dbh->do("select 1 from dual");
print "first ok = $ok\n";
print "sleep 501\n";
sleep(501);
print "2nd select\n";
$ok = $dbh->do("select 1 from dual");
print "2nd ok = $ok\n";
print "first disconnect\n";
$dbh->disconnect;
if(!defined($ok)){
print "2nd connect\n";
$dbh1 = DBI->connect('dbi:Oracle:','...','...');
print "last select\n";
$ok = $dbh1->do("select 1 from dual");
print "last ok = $ok\n";
print "last disconnect\n";
$dbh1->disconnect;
}
After sleeping 501 seconds, the 2nd 'select 1 from dual' failed with "DBD::Oracle::db ping failed: ORA-03113: end-of-file on communication channel" error, since DRCP MAX_THINK_TIME is configured for 500. The $ok is undef. In the case if the test does succeed (like the first select), $ok returns 0E0. Since I changed DBD::Oracle subroutine ping to use 'select 1 from dual', the code in Apache::DBI subroutine connect needs to be changed also. I attempted to change it like the following:
200 if ($Connected{$Idx} and ($needping) ) {
201 my $ok = eval{$Connected{$Idx}->ping};
202
203 if(defined($ok) and $ok == 0) {
204 debug(2, "$prefix already connected to '$Idx'");
205
206 # Force clean up of handle in case previous transaction failed to
207 # clean up the handle
208 &reset_startup_state($Idx);
209
210 return (bless $Connected{$Idx}, 'Apache::DBI::db');
211 }
212 }
Do you think the above code is good?
If I changed the Apache::DBI source code because I used different ping method in DBD::Oracle, what's the best way to maintain this new code? Whenever I upgrade this module, would it overwrite the change I made? This is the same question for DBD::Oracle.
I have another request. 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 good. Can you please identify and change the code for this problem?
Thanks,
- xinhuan
From: Perrin Harkins <ph...@gmail.com>>
Date: Thursday, November 7, 2013 8:16 AM
To: Xinhuan Zheng <xz...@christianbook.com>>
Cc: mod_perl list <mo...@perl.apache.org>>
Subject: Re: Apache::DBI connect
Have you used the DRCP settings in DBD::Oracle?
http://search.cpan.org/~pythian/DBD-Oracle-1.66/lib/DBD/Oracle.pm#Oracle_DRCP
>From the description of DRCP, it sounds like you should never lose the connection. You may want to check the configuration.
>From your debugging output, it looks like the line that tries to re-connect is failing. I'd add some debugging statements to confirm that, and then try writing a simple script outside of mod_perl that tries to re-connect to Oracle after you drop the connection from the Oracle side. To figure out more, you'll probably need to talk to whoever maintains DBD::Oracle.
- Perrin
On Wed, Nov 6, 2013 at 8:55 PM, Xinhuan Zheng <xz...@christianbook.com>> wrote:
Hi Perrin,
I am using Oracle Resident Connection Pool feature. The application randomly got "ORA-03114 not connect to oracle database" error. As per this document:
http://search.cpan.org/~phred/Apache-DBI-1.12/lib/Apache/DBI.pm
I have changed the DBD::Oracle to use the following ping instead of ora_ping:
sub ping {
my ($dbh) = @_;
my $ret = 0;
eval {
local $SIG{__DIE__} = sub { return (0); };
local $SIG{__WARN__} = sub { return (0); };
# adapt the select statement to your database:
$ret = $dbh->do('select 1');
};
return ($@) ? 0 : $ret;
}
After this change, the application can detect "end-of-file communication" error then after the application establishes new connection, the application still throws "ORA-03114 not connect to oracle database" error.
below is the errors when Apache::DBI debug is set:
3861 Apache::DBI need ping: yes
DBD::Oracle::db ping failed: ORA-03113: end-of-file on communication channel
Process ID: 29671
Session ID: 3219 Serial number: 544 (DBD ERROR: OCIStmtExecute/Describe) at /usr/local/lib/perl5/site_perl/5.8.3/Apache/DBI.pm line 200.
3861 Apache::DBI new connect to '...'
3861 Apache::DBI need ping: yes
3861 Apache::DBI already connected to '...'
3861 Apache::DBI need ping: yes
3861 Apache::DBI already connected to '...'
3861 Apache::DBI need ping: yes
3861 Apache::DBI already connected to '...'
3861 Apache::DBI need ping: yes
3861 Apache::DBI already connected to '...'
3861 Apache::DBI need ping: yes
3861 Apache::DBI already connected to '...'
3861 Apache::DBI need ping: yes
3861 Apache::DBI already connected to '...'
3861 Apache::DBI need ping: yes
DBD::Oracle::st execute failed: ORA-03114: not connected to ORACLE (DBD ERROR: OCIStmtExecute)
3861 Apache::DBI need ping: yes
3861 Apache::DBI already connected to ''
3861 Apache::DBI disconnect (overloaded)
[Wed Nov 6 16:49:50 2013] [crit] ORA-03114: not connected to ORACLE (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 <ph...@gmail.com>>
Date: Wednesday, November 6, 2013 5:54 PM
To: Xinhuan Zheng <xz...@christianbook.com>>
Cc: mod_perl list <mo...@perl.apache.org>>
Subject: Re: Apache::DBI connect
On Wed, Nov 6, 2013 at 4:07 PM, Xinhuan Zheng
<xz...@christianbook.com>> 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 difference between DBI->connect
vs $drh->connect?
The $drh there is a DBI driver, not a database handle. It should return a new connection every time. You can try putting in DBI->connect() there and see if it fixes the problem for you though. If not, I'd suggest reporting the problem as a DBD::Oracle issue.
By the way, which Oracle pooling solution are you using and how is it working out for you, aside from this problem?
- Perrin
Re: Apache::DBI connect
Posted by Perrin Harkins <ph...@gmail.com>.
Have you used the DRCP settings in DBD::Oracle?
http://search.cpan.org/~pythian/DBD-Oracle-1.66/lib/DBD/Oracle.pm#Oracle_DRCP
>From the description of DRCP, it sounds like you should never lose the
connection. You may want to check the configuration.
>From your debugging output, it looks like the line that tries to re-connect
is failing. I'd add some debugging statements to confirm that, and then
try writing a simple script outside of mod_perl that tries to re-connect to
Oracle after you drop the connection from the Oracle side. To figure out
more, you'll probably need to talk to whoever maintains DBD::Oracle.
- Perrin
On Wed, Nov 6, 2013 at 8:55 PM, Xinhuan Zheng <xz...@christianbook.com>wrote:
> Hi Perrin,
>
> I am using Oracle Resident Connection Pool feature. The application
> randomly got "ORA-03114 not connect to oracle database" error. As per this
> document:
>
> http://search.cpan.org/~phred/Apache-DBI-1.12/lib/Apache/DBI.pm
>
> I have changed the DBD::Oracle to use the following ping instead of
> ora_ping:
>
> sub ping {
> my ($dbh) = @_;
> my $ret = 0;
> eval {
> local $SIG{__DIE__} = sub { return (0); };
> local $SIG{__WARN__} = sub { return (0); };
> # adapt the select statement to your database:
> $ret = $dbh->do('select 1');
> };
> return ($@) ? 0 : $ret;
> }
>
> After this change, the application can detect "end-of-file
> communication" error then after the application establishes new connection,
> the application still throws "ORA-03114 not connect to oracle database"
> error.
>
> below is the errors when Apache::DBI debug is set:
>
> 3861 Apache::DBI need ping: yes
> DBD::Oracle::db ping failed: ORA-03113: end-of-file on communication
> channel
> Process ID: 29671
> Session ID: 3219 Serial number: 544 (DBD ERROR: OCIStmtExecute/Describe)
> at /usr/local/lib/perl5/site_perl/5.8.3/Apache/DBI.pm line 200.
> 3861 Apache::DBI new connect to '...'
> 3861 Apache::DBI need ping: yes
> 3861 Apache::DBI already connected to '...'
> 3861 Apache::DBI need ping: yes
> 3861 Apache::DBI already connected to '...'
> 3861 Apache::DBI need ping: yes
> 3861 Apache::DBI already connected to '...'
> 3861 Apache::DBI need ping: yes
> 3861 Apache::DBI already connected to '...'
> 3861 Apache::DBI need ping: yes
> 3861 Apache::DBI already connected to '...'
> 3861 Apache::DBI need ping: yes
> 3861 Apache::DBI already connected to '...'
> 3861 Apache::DBI need ping: yes
> DBD::Oracle::st execute failed: ORA-03114: not connected to ORACLE (DBD
> ERROR: OCIStmtExecute)
> 3861 Apache::DBI need ping: yes
> 3861 Apache::DBI already connected to ''
> 3861 Apache::DBI disconnect (overloaded)
> [Wed Nov 6 16:49:50 2013] [crit] ORA-03114: not connected to ORACLE
> (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 <ph...@gmail.com>
> Date: Wednesday, November 6, 2013 5:54 PM
> To: Xinhuan Zheng <xz...@christianbook.com>
> Cc: mod_perl list <mo...@perl.apache.org>
> Subject: Re: Apache::DBI connect
>
>
>
> On Wed, Nov 6, 2013 at 4:07 PM, Xinhuan Zheng
> <xz...@christianbook.com> 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 difference between DBI->connect
> vs $drh->connect?
>
>
>
> The $drh there is a DBI driver, not a database handle. It should return
> a new connection every time. You can try putting in DBI->connect() there
> and see if it fixes the problem for you though. If not, I'd suggest
> reporting the problem as a DBD::Oracle issue.
>
> By the way, which Oracle pooling solution are you using and how is it
> working out for you, aside from this problem?
>
> - Perrin
>
>
>
Re: Apache::DBI connect
Posted by Xinhuan Zheng <xz...@christianbook.com>.
Hi Perrin,
I am using Oracle Resident Connection Pool feature. The application randomly got "ORA-03114 not connect to oracle database" error. As per this document:
http://search.cpan.org/~phred/Apache-DBI-1.12/lib/Apache/DBI.pm
I have changed the DBD::Oracle to use the following ping instead of ora_ping:
sub ping {
my ($dbh) = @_;
my $ret = 0;
eval {
local $SIG{__DIE__} = sub { return (0); };
local $SIG{__WARN__} = sub { return (0); };
# adapt the select statement to your database:
$ret = $dbh->do('select 1');
};
return ($@) ? 0 : $ret;
}
After this change, the application can detect "end-of-file communication" error then after the application establishes new connection, the application still throws "ORA-03114 not connect to oracle database" error.
below is the errors when Apache::DBI debug is set:
3861 Apache::DBI need ping: yes
DBD::Oracle::db ping failed: ORA-03113: end-of-file on communication channel
Process ID: 29671
Session ID: 3219 Serial number: 544 (DBD ERROR: OCIStmtExecute/Describe) at /usr/local/lib/perl5/site_perl/5.8.3/Apache/DBI.pm line 200.
3861 Apache::DBI new connect to '...'
3861 Apache::DBI need ping: yes
3861 Apache::DBI already connected to '...'
3861 Apache::DBI need ping: yes
3861 Apache::DBI already connected to '...'
3861 Apache::DBI need ping: yes
3861 Apache::DBI already connected to '...'
3861 Apache::DBI need ping: yes
3861 Apache::DBI already connected to '...'
3861 Apache::DBI need ping: yes
3861 Apache::DBI already connected to '...'
3861 Apache::DBI need ping: yes
3861 Apache::DBI already connected to '...'
3861 Apache::DBI need ping: yes
DBD::Oracle::st execute failed: ORA-03114: not connected to ORACLE (DBD ERROR: OCIStmtExecute)
3861 Apache::DBI need ping: yes
3861 Apache::DBI already connected to ''
3861 Apache::DBI disconnect (overloaded)
[Wed Nov 6 16:49:50 2013] [crit] ORA-03114: not connected to ORACLE (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 <ph...@gmail.com>>
Date: Wednesday, November 6, 2013 5:54 PM
To: Xinhuan Zheng <xz...@christianbook.com>>
Cc: mod_perl list <mo...@perl.apache.org>>
Subject: Re: Apache::DBI connect
On Wed, Nov 6, 2013 at 4:07 PM, Xinhuan Zheng
<xz...@christianbook.com>> 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 difference between DBI->connect
vs $drh->connect?
The $drh there is a DBI driver, not a database handle. It should return a new connection every time. You can try putting in DBI->connect() there and see if it fixes the problem for you though. If not, I'd suggest reporting the problem as a DBD::Oracle issue.
By the way, which Oracle pooling solution are you using and how is it working out for you, aside from this problem?
- Perrin
Re: Apache::DBI connect
Posted by Perrin Harkins <ph...@gmail.com>.
On Wed, Nov 6, 2013 at 4:07 PM, Xinhuan Zheng <xz...@christianbook.com>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 difference between DBI->connect vs $drh->connect?
The $drh there is a DBI driver, not a database handle. It should return a
new connection every time. You can try putting in DBI->connect() there and
see if it fixes the problem for you though. If not, I'd suggest reporting
the problem as a DBD::Oracle issue.
By the way, which Oracle pooling solution are you using and how is it
working out for you, aside from this problem?
- Perrin