ID:               16183
 Updated by:       [EMAIL PROTECTED]
 Reported By:      [EMAIL PROTECTED]
-Status:           Open
+Status:           Bogus
 Bug Type:         OCI8 related
 Operating System: RedHat 7.2
 PHP Version:      4.1.2
 New Comment:

Please do not open two bugreports about the same problem.


Previous Comments:
------------------------------------------------------------------------

[2002-03-20 07:00:14] [EMAIL PROTECTED]

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.

------------------------------------------------------------------------


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

Reply via email to