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.