• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 949
  • Last Modified:

PHP + Oracle persistent connections problem

I have recently enabled persistent connection from our PHP application to Oracle by using oci_pconnect instead of oci_connect. 99% of the application works fine, but one specific script has problems. The problem is that I bind some variables by using oci_bind_by_name and I get an error that those variables are not binded. The script works 100% without persistent connections, and sometimes is works sometimes is does not work with persistent connections. Is there a sharing of bind variables when I use persistent connections, and multiple requests to the same script reset each-other's variables, or something similar to that? Otherwise I can't find out why it works sometimes and I can't predict the error.
0
bogdan_etechnics
Asked:
bogdan_etechnics
1 Solution
 
poisaCommented:
I'm not sure this is the case with Oracle but persistent connections with MySQL have been buggy (and risky) for a while in php. I tried to use them several times and never had god consistency.

Two things from the PHP manual that *might* be able to assist you (although it would seem that you have another problem, but there is no such thing as too much info, right?):

1) Warning:
There are a couple of additional caveats to keep in mind when using persistent connections. One is that when using table locking on a persistent connection, if the script for whatever reason cannot release the lock, then subsequent scripts using the same connection will block indefinitely and may require that you either restart the httpd server or the database server. Another is that when using transactions, a transaction block will also carry over to the next script which uses that connection if script execution ends before the transaction block does. In either case, you can use register_shutdown_function() to register a simple cleanup function to unlock your tables or roll back your transactions. Better yet, avoid the problem entirely by not using persistent connections in scripts which use table locks or transactions (you can still use them elsewhere).

2) (snip) Note, however, that this can have some drawbacks if you are using a database with connection limits that are exceeded by persistent child connections. If your database has a limit of 16 simultaneous connections, and in the course of a busy server session, 17 child threads attempt to connect, one will not be able to. If there are bugs in your scripts which do not allow the connections to shut down (such as infinite loops), the database with only 16 connections may be rapidly swamped. Check your database documentation for information on handling abandoned or idle connections.

I'll keep looking to see if I can find something a little bit more useful for your situation.
0
 
CWS (haripriya)Commented:
No comment has been added to this question in more than 21 days, so it is now classified as abandoned.

I will leave the following recommendation for this question in the Cleanup topic area:
   Accept: poisa {http:#20503865}

Any objections should be posted here in the next 4 days. After that time, the question will be closed.

cyberwebservice
Experts Exchange Cleanup Volunteer
0
 
Computer101Commented:
Forced accept.

Computer101
EE Admin
0

Featured Post

What does it mean to be "Always On"?

Is your cloud always on? With an Always On cloud you won't have to worry about downtime for maintenance or software application code updates, ensuring that your bottom line isn't affected.

Tackle projects and never again get stuck behind a technical roadblock.
Join Now