views:

86

answers:

2

I'm experiencing some behavior I did not expect. I have a synchronous procedure that is kicked off via PHP/OCI8. At the beginning of the process there is a SELECT...FOR UPDATE NOWAIT

I do NOWAIT because I want users notified immediately with an error message that the process is already running, rather than having their browser wait for the lock.

When I run the process from two separate computers with two separate PHP sessions, I get the expected behavior: one runs while the other gets an ORA-00054: resource busy and acquire with NOWAIT specified.

But when I open two tabs on the same browser and run the process, the second tab waits the 30+ seconds for the first one to finish, and then runs the second one -- it's as if I did not specify NOWAIT.

I'm not using persistent connections or connection pooling of any kind. I thought a separate HTTP request, executing separate PHP=>Oracle connections, would give me separate DB sessions. Is this not the case?

UPDATE: I found this: http://wiki.oracle.com/page/PHP+Oracle+FAQ under #6, How do I connect to Oracle with the OCI8 extension? it says:

PHP will share/re-use connections if the same user credentials are used more than once in a script or httpd server session. You can use the oci_new_connect() function to ensure a new session is used. Call the oci_pconnect() function to make a persistent connection that isn't closed at the end of the script (making the reconnection in the next script much faster).

However, when I change to oci_new_connect it does not fix the issue. Different sessions on different computers throw the ORA-00054, but two tabs on the same browser synchronize access but do not respect the NOWAIT.

A: 

Remember, there is "loadsession" and then there is "savesession"

It is possible that another process udpates the php session in this interval depending on how your session driver works.

krico
@krico: Sorry, I'm not familiar with either of these. We store our sessions in a separate database, but it works very similarly to the default php file-based session mechanism. Assuming that both tabs shared the same session, are you saying that internally PHP would associate that shared session with a single DB session?
RenderIn
No, the database session would be a different one. However, if you also load the php-session with a FOR UPDATE, chances are the script hangs on starting the PHP session, not on waiting for the other FOR UPDATE procedure.
Wrikken
The PHP session is not being loaded with a FOR UPDATE.
RenderIn
Now that I debug it a little more I can confirm your suspicion that it is not even getting to the SQL execution for the second script. For some reason it's not even starting to process the second script until the first is completed. It doesn't even get to the point where it calls the session handlers until the first script completes. Any idea why this could be?
RenderIn
A: 

Okay, so this is not a database issue at all. It seems instead that Firefox 3.6.6 queued my simultaneous requests and it wasn't a PHP or DB session issue after all. See this question for an exploration of that issue: http://stackoverflow.com/questions/3284295/does-firefox-synchronize-requests-for-the-same-page

RenderIn