#26829 [Sus]: Killed Oracle Sessions openned with OCIPLogon()

2004-02-13 Thread david dot gaia dot kano at dartmouth dot edu
 ID:   26829
 User updated by:  david dot gaia dot kano at dartmouth dot edu
 Reported By:  david dot gaia dot kano at dartmouth dot edu
 Status:   Suspended
 Bug Type: OCI8 related
 Operating System: Compaq Unix
 PHP Version:  4.3.4
 Assigned To:  tony2001
 New Comment:

Sorry for the delayed respose, sniper. We have been working around this
Ok and I'm finally getting back to checking this bug status.



To clarify, the issue is that our Oracle Administrators have
proceedures that automatically kill any session that has been running
for longer than 24 hours. So no, it is not an issue of the connection
being killed while the script is running.



I think we can wait for php 5 to address this, rather than building a
"latest" php 4 release from CVS. I'm hoping that will be available
fairly soon anyway because I'm excited about the new features! If it is
not released soon, I'll probably build it on my test server and then
check this bug out there to confirm it is fixed.


Previous Comments:


[2004-02-04 04:01:25] [EMAIL PROTECTED]

This is known issue and should be fixed in future releases of PHP5.





[2004-01-19 14:12:22] [EMAIL PROTECTED]

No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Open". Thank you.





[2004-01-07 20:14:23] [EMAIL PROTECTED]

Please try using this CVS snapshot:

  http://snaps.php.net/php4-STABLE-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php4-win32-STABLE-latest.zip

AFAICT, the function does check if persistent connection is still alive
(using oci_ping())..but did you mean the connection is killed while the
script is being run or what?



--------

[2004-01-07 11:36:45] david dot gaia dot kano at dartmouth dot edu

Description:

Here at Dartmouth our DBA team has a policy of killing any Oracle
session that has been connected for longer than 24 hours. Hence the
persistant connections created by the PHP OCIPLogon() call get killed
once a day. We don't really want to restart our apache server once a
day, so it would be great if OCIPLogon() would check to see that a
previously created persistant connection is still good somehow and if
not, create a new connection.



I noticed quite a few bugs along these lines, but they have all been
closed. I don't know if that is because this bug was fixed or because
the submitters have continued to restart their servers after every
database restart or killed connection.



If this is not going to be fixed, I guess we would have to write our
own application level code to check the connections from ociplogon()
and if it is bad, use OCILogon() instead for that request and issue a
apache_child_terminate() call so that eventually all the children with
bad oracle sessions would be restarted...

Reproduce code:
---
$con = OCIPLogon("user", "password", "tns_db_name");

// at this point all looks good still... $con != false

// but if this session was killed then any use of $con 

// results in one error or another.






-- 
Edit this bug report at http://bugs.php.net/?id=26829&edit=1


#26829 [NEW]: Killed Oracle Sessions openned with OCIPLogon()

2004-01-07 Thread david dot gaia dot kano at dartmouth dot edu
From: david dot gaia dot kano at dartmouth dot edu
Operating system: Compaq Unix
PHP version:  4.3.4
PHP Bug Type: OCI8 related
Bug description:  Killed Oracle Sessions openned with OCIPLogon()

Description:

Here at Dartmouth our DBA team has a policy of killing any Oracle session
that has been connected for longer than 24 hours. Hence the persistant
connections created by the PHP OCIPLogon() call get killed once a day. We
don't really want to restart our apache server once a day, so it would be
great if OCIPLogon() would check to see that a previously created
persistant connection is still good somehow and if not, create a new
connection.

I noticed quite a few bugs along these lines, but they have all been
closed. I don't know if that is because this bug was fixed or because the
submitters have continued to restart their servers after every database
restart or killed connection.

If this is not going to be fixed, I guess we would have to write our own
application level code to check the connections from ociplogon() and if it
is bad, use OCILogon() instead for that request and issue a
apache_child_terminate() call so that eventually all the children with bad
oracle sessions would be restarted...

Reproduce code:
---
$con = OCIPLogon("user", "password", "tns_db_name");
// at this point all looks good still... $con != false
// but if this session was killed then any use of $con 
// results in one error or another.


-- 
Edit bug report at http://bugs.php.net/?id=26829&edit=1
-- 
Try a CVS snapshot (php4):  http://bugs.php.net/fix.php?id=26829&r=trysnapshot4
Try a CVS snapshot (php5):  http://bugs.php.net/fix.php?id=26829&r=trysnapshot5
Fixed in CVS:   http://bugs.php.net/fix.php?id=26829&r=fixedcvs
Fixed in release:   http://bugs.php.net/fix.php?id=26829&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=26829&r=needtrace
Need Reproduce Script:  http://bugs.php.net/fix.php?id=26829&r=needscript
Try newer version:  http://bugs.php.net/fix.php?id=26829&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=26829&r=support
Expected behavior:  http://bugs.php.net/fix.php?id=26829&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=26829&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=26829&r=submittedtwice
register_globals:   http://bugs.php.net/fix.php?id=26829&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=26829&r=php3
Daylight Savings:   http://bugs.php.net/fix.php?id=26829&r=dst
IIS Stability:  http://bugs.php.net/fix.php?id=26829&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=26829&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=26829&r=float


#3910 [Com]: persistent connections persist even after a kill session has been done on them.

2004-01-06 Thread david dot gaia dot kano at dartmouth dot edu
 ID:   3910
 Comment by:   david dot gaia dot kano at dartmouth dot edu
 Reported By:  guage at usa dot net
 Status:   Closed
 Bug Type: Oracle related
 Operating System: Linux - Redhat 6.1
 PHP Version:  4.0.01pl2
 New Comment:

This is happening on our server using PHP 4.3.4

Should this be reopened?


Previous Comments:


[2003-08-08 04:46:26] [EMAIL PROTECTED]

wrong version -> bug got lost, but is propably fixed in later versions
of PHP anyway.




[2000-08-21 12:26:06] 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



[2000-08-21 12:19:48] guage at usa dot net

Bug still exists.  I have verified for php 4.0.1pl2

Thanks...



[2000-08-20 01:54:04] [EMAIL PROTECTED]

No feedback from user.

--Jani



[2000-08-01 23:30:25] [EMAIL PROTECTED]

Please verify that it´s still happening using the latest version of PHP
(release 4.0.1pl2 or CVS).



The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/3910

-- 
Edit this bug report at http://bugs.php.net/?id=3910&edit=1