php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #16183 Problem with multiple sessions on a persistent connection
Submitted: 2002-03-20 07:00 UTC Modified: 2002-04-13 09:17 UTC
From: msquillace at sogei dot it Assigned:
Status: Closed Package: OCI8 related
PHP Version: 4.1.2 OS: RedHat 7.2
Private report: No CVE-ID: None
View Add Comment Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
You can add a comment by following this link or if you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: msquillace at sogei dot it
New email:
PHP Version: OS:

 

 [2002-03-20 07:00 UTC] msquillace at sogei dot it
Environment is Linux RedHat 7.2, Apache 1.3.23, PHP 4.1.2 DSO with OCI8 (8.1.7.0) and several other extensions; the Oracle database (8.1.7.3) is on a Win2k server.

This bug report stems from an attempt to overcome the problem described in bug#16181.

I have a script implementing session handling against Oracle that's included at the top of each and every page of an application.

I cannot share the transaction context with the application but want to create a single, persistent connection to the DB, so I use OCIPlogon('user1', 'pwd1', 'alias') in the included file, while the application connects with OCIPlogon('user2', 'pwd2', 'alias').

If I query the v$session table for username,process,status I observe two sessions per process, which is expected; the number of processes is equal to the active Apache processes, which is also expected since I am currently not using the Oracle multithreaded server (MTS).

This appears to work 99.9% of the time, even though I am not 100% sure I am getting different transaction contexts with the OCIPLogons (the manual could be clearer on these fine points).

Problem is that randomly, when the session handling code is writing down the updated session variables at script end, Oracle responds with ORA-00942: table or view does not exist.

I traced the requests on the server side and discovered that, while the request is correctly formed it is associated with 'user2' instead of 'user1'; this explains the error since 'user2' is not granted access to the session table.

I believe this is a bug, since there is no evidence of transaction context problems and maybe the OCI8 extension is just selecting the wrong user from its internal session cache.

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2002-03-21 06:17 UTC] sander@php.net
Please do not open two bugreports about the same problem.
 [2002-03-21 08:32 UTC] msquillace at sogei dot it
This is related to the same script as bug#16181, but the OCI8 functions used are not the same (two OCIPLogon for both 'user1' and 'user2' instead of one OCIPLogon for 'user1' and an OCINLogon for 'user2'), and more importantly the malfunction observed is quite different.
IMHO it may be worth investigating both.
 [2002-04-13 09:17 UTC] thies@php.net
This bug has been fixed in CVS.


 [2002-04-15 12:52 UTC] msquillace at sogei dot it
Thank you Thies!

Can you please confirm I am getting two different, independent transaction contexts in this scenario?
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Fri Mar 29 13:01:29 2024 UTC