php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Bug #3910 persistent connections persist even after a kill session has been done on them.
Submitted: 2000-03-23 13:59 UTC Modified: 2006-07-17 09:00 UTC
Votes:4
Avg. Score:4.5 ± 0.9
Reproduced:2 of 3 (66.7%)
Same Version:0 (0.0%)
Same OS:0 (0.0%)
From: guage at usa dot net Assigned:
Status: Closed Package: OCI8 related
PHP Version: 4.0.01pl2 OS: Linux - Redhat 6.1
Private report: No CVE-ID: None
View Developer Edit
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If you forgot your password, you can retrieve your password here.
Password:
Status:
Package:
Bug Type:
Summary:
From: guage at usa dot net
New email:
PHP Version: OS:

 

 [2000-03-23 13:59 UTC] guage at usa dot net 
In reading the source code in Beta 4.0 it states that OCILogoff doesn't do anything anymore.  This is a problem because when a session is killed on the database side the connection remains for ever on the server and you receive ORA-0028 errors when ever you hit an httpd server which has that particular session.  The only solution is to restart the httpd server.
To reproduce:
1. create a script which does an ociplogon and then executes a statement.
2. hit reload several times to increase the chance you will hit an httpd after you kill a session which has already established a connection to the database.
3. on the server type:
    select username,sid,serial# from v$session where username = '<username you connected with in ociplogon>';
4. do a:
   alter system kill session '<sid>,<serial#>'; 
   for each of the sessions.
5. hit reload on your browser.

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2000-08-01 23:30 UTC] waldschrott@php.net 
Please verify that it?s still happening using the latest version of PHP (release 4.0.1pl2 or CVS).
 [2000-08-20 01:54 UTC] sniper@php.net 
No feedback from user.

--Jani
 [2000-08-21 12:19 UTC] guage at usa dot net 
Bug still exists.  I have verified for php 4.0.1pl2

Thanks...
 [2000-08-21 12:26 UTC] guage at usa dot net 
OciLogoff seems to do something now but does not clear a connection that has been killed on the oracle server (at least when ociplogon is used).  The only way to recover from this situation is to restart the httpd server.  I have tried to create a new connection via ociplogon but it continues to try to use the old connection which was killed.  OCIPlogon returns a success but ociexecute returns an error.  
connecting to oracle Connected successfully 
^- does a ociplogon

Warning: OCIStmtExecute: ORA-00028: your session has been killed in
orabugtest.php on line 12
^--- this is from a ociexecute

killing session !!!!!  <--- this does a ocilogoff

Warning: failed to rollback outstanding transactions!: ORA-01012: not logged on in
orabugtest.php on line 16

Warning: OCIFetchStatement: OCI_INVALID_HANDLE in
orabugtest.php on line 18
 [2003-08-08 04:46 UTC] sniper@php.net 
wrong version -> bug got lost, but is propably fixed in later versions of PHP anyway.
 [2004-01-06 15:13 UTC] david dot gaia dot kano at dartmouth dot edu 
This is happening on our server using PHP 4.3.4

Should this be reopened?
 [2004-09-24 21:00 UTC] michael dot virnstein at brodos dot de 
bug still exists when using php as apache module
If you use OCIPLogon, the function doesn't recognize if the connection is still valid from the oracle side. It seems to still think there is a valid connection and returns the handle. PHP recognize it, when you try to use any other OCI-Function on the connection. I've observed, that after that, the connection gets reastablished if possible. If the DB went down and got up again, you can observe it quite nicely by hitting REFRESH a few times. 
try to use this code:
<?php

$conn = ociPLogin("username", "password", "db");

$stmt = ociParse("Select sysdate time from dual");

ociDefinceByName($stmt, "time", $var);

ociExecute($stmt);

ociFetch($stmt);

echo $var;
?>

Steps to reproduce:
1. Be sure the DB is up.
2. Load page a few times -> time will get displayed
3. Restart DB and wait for it to finish
4. Open Page again -> you'll get an error on ociParse
5. Now hit refresh a few times. First you'll probably get the error on the ociParse again, but after a few times,it'll start working again, but it'll switch between working and non-working. 
It seem, that every apache process that is running with a corrupted php-db-connection, reastablishes the connection after the error. If you have luck with the REFRESH, your request will be handled by a process with an already reastablished connection, if not you get the error.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved. 		Last updated: Sun Dec 22 01:01:30 2024 UTC