php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #36634 oci8.persistent_timeout not functioning
Submitted: 2006-03-06 20:12 UTC Modified: 2006-03-17 18:49 UTC
From: zhang_yinshu at yahoo dot com Assigned:
Status: Not a bug Package: OCI8 related
PHP Version: 5.1.2 OS: Gentoo Linux
Private report: No CVE-ID: None
 [2006-03-06 20:12 UTC] zhang_yinshu at yahoo dot com
Description:
------------
oci8.persistent_timeout not functioning does not close connection after specified period expired. even with oci8.ping_interval disabled


Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2006-03-06 20:22 UTC] tony2001@php.net
Not enough information was provided for us to be able
to handle this bug. Please re-read the instructions at
http://bugs.php.net/how-to-report.php

If you can provide more information, feel free to add it
to this bug and change the status back to "Open".

Thank you for your interest in PHP.



 [2006-03-06 21:02 UTC] zhang_yinshu at yahoo dot com
[did] specify below statements in php.ini
oci8.max_persistent = 20
oci8.persistent_timeout = 60
oci8.ping_interval  = -1

info() confirm with

oci8
OCI8 Support 	enabled
Revision 	$Revision: 1.269.2.8 $
Active Persistent Connections 	0
Active Connections 	0
Oracle Version 	9.2
Compile-time ORACLE_HOME 	/oracle/product/9.2.0
Libraries Used 	no value
Temporary Lob support 	enabled
Collections support 	enabled

oci8.default_prefetch	10	10
oci8.max_persistent	20	20
oci8.old_oci_close_semantics	0	0
oci8.persistent_timeout	60	60
oci8.ping_interval	-1	-1
oci8.privileged_connect	Off	Off
oci8.statement_cache_size	20	20


[want]: oracle session opened by oci_pconnection be closed after inactive for 60sec.
[see]: oracle session persist.
 [2006-03-06 21:06 UTC] tony2001@php.net
How do you determine if they are "inactive" or not?
 [2006-03-06 21:08 UTC] zhang_yinshu at yahoo dot com
by query v$session view from Oracle database
 [2006-03-06 21:16 UTC] tony2001@php.net
And you don't run any PHP scripts in the same time?
 [2006-03-06 21:27 UTC] zhang_yinshu at yahoo dot com
a test script of course, use class:
<?
include ('db.class.php');
$db=new db('xxxxx','xxxx','xxxxxx');
$db->query("select * from tab");
echo $db->to_string();
?>

part of db.class.php:

function db_open($user,$pass,$db)
{
if (!$this -> _connection = oci_pconnect($user,$pass,$db))  {
err ("Can not open database connection user:$user,db:$db, error:".print_r(ocierror()));
$this->__destruct();
}
}
 [2006-03-07 08:38 UTC] tony2001@php.net
oci_pconnect() means you're using these connections in a script, so they do not timeout because of that.
No bug here.
 [2006-03-07 18:02 UTC] zhang_yinshu at yahoo dot com
OMG, I was such a fool, I didnt wait 60sec. after that script use the connection, ....oh, wait, i did wait. Actually no matter how long i wait, connection hungup there as idel.
 [2006-03-17 05:16 UTC] zhang_yinshu at yahoo dot com
can anybody look at this issue, anybody, whoever have knoweldge of oracle database.
 [2006-03-17 10:00 UTC] tony2001@php.net
1) Set oci8.persistent_timeout to 10 seconds.
2) Restart Apache.
3) Open several persistent connections and check if they are present in v$process.
4) Wait for 10 seconds.
5) Run _empty_ PHP script with just <?php ?> several times.
6) Check v$process. 
7) Voila - connections are not there anymore!

No bug -> bogus.
 [2006-03-17 15:11 UTC] zhang_yinshu at yahoo dot com
v$process only show active sessions, use v$session please, and run your test again.
 [2006-03-17 15:48 UTC] tony2001@php.net
SQL>  select user from v$session;
........
16 rows selected.

10 seconds later:

SQL>  select user from v$session;
........
9 rows selected.


Please next time do it yourself and don't waste my time.
 [2006-03-17 18:05 UTC] zhang_yinshu at yahoo dot com
try this and see last activity is way beyond timeout. I realized I am wasting your time, so stop working on the case and read "Oracle for dummy", so someone else can help.

select s.program,
to_char(sysdate,'mm/dd/yy hh24:mi:ss') now,
to_char(sysdate - (s.last_call_et)/86400,'mm/dd/yy hh24:mi:ss') last_act_dt
from v$process p, v$session s
where s.username is not null
and s.program like 'httpd%'
and s.paddr = p.addr
order by s.logon_time
/
 [2006-03-17 18:17 UTC] tony2001@php.net
>read "Oracle for dummy"
Yeah, I remember reading something like this when I was writing ext/oci8 module.

Please stop reopening the report, nobody is going to help you in solving problems that do not exist.
 [2006-03-17 18:49 UTC] zhang_yinshu at yahoo dot com
First of all, I apology for anything I said inappropriate, I am very appreciate PHP OCI8 doing great job and all your effort.

However, I got my mind set to this(please help correct me if you are not angre anymore), if i use persistent connection, when there's PHP finish query with database, oracle session will remain inactive unless PHP reuse same session. If I set oci9.persistent_timeout, inactive session should be closed, next PHP connection will open new session.

My problem is my PHP session keep inactive in database and never got disconnect unless I stop apache. I would be more than happy if you can point out anything I compile/configure wrong.
 [2010-07-30 19:55 UTC] wertygol at gmail dot com
I have the same problem, but this time is not Apache but IIS 5.1. When I use apache server the pconnect works fine but in IIS never close the idle connections on the Oracle 10G Database.
 [2011-11-12 17:24 UTC] walovaton at yahoo dot com dot mx
Hello there, I just want to say that everything you need to understand this "problem" is right there in the manual.  PHP can only check if a connection is idle as long as the process itself is doing something, in this case serving a request.  So for this thing to work PHP needs to receive a request that does not touch the Oracle connection to have a chance to see if the connection is idle enough to close it.

Like the manual suggests, it's a chicken-egg situation.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Thu May 02 03:01:29 2024 UTC