The leading edge of scripting languages and Oracle Database brought to you by the Data Access Development team
-
php
April 18, 2008
PHP PECL OCI8 1.3.2 Beta Available
I've released PECL OCI8 1.3.2 Beta - the latest release of PHP's OCI8 extension with support for Connection Pooling and Fast Application Notification. The release is based on the current PHP 5.3 development branch.
The development team has been hard at work refactoring, tuning, stress testing, and benchmarking the code. The code has come a long way since our first release of 1.3 last year. I feel that 1.3.2 should be the last Beta.
One change since 1.3.1 that I should mention, is that oci_pconnect() persistent connections will now do a "session release" (an OCI8-implementation internal operation) if the end of scope is reached (for example at the end of a function) and there are no PHP variables referencing the connection resource. The implication is that a rollback will happen - silently. It brings persistent connection behavior in line with normal connections. This makes the API more predictable. It allows applications to change between non-persistent and persistent connections more easily. It makes the implementation of OCI8 cleaner, and allows greater resource efficiency.
We evaluated the impact with the co-operation of our Beta testers. The change doesn't affect PHP OCI8 scripts that do one or more of:
- Pass a oci_pconnect() connection resource between functions
- Auto-commit
- Explicitly commit or roll back transactions
- Use oci_connect() or oci_new_connect()
Code that doesn't do any of them, and instead relies on transactions in persistent connections being open beyond the end of scope, might already be subject to seemingly random or "delicate" behavior. PHP's internal use of ref-counting sometimes makes it hard to predict when resources actually get released. For the very few people affected by the OCI8 persistent connection change, the behavior will be clearer and more consistent, and there is an incentive to code in a more logical style.
But to ease any lingering upgrading issues, setting oci8.old_oci_close_semantics=1 will cause connection closes to be no-ops, just like the old days.
Join the discussion
-
Hmm, maybe I am not understanding this implicit rollback feature properly. So any transaction started inside a function/method should also be finished in the same function/method? I guess its a fine assumption, but can also break a lot of code (especially that nasty kind of code that uses exceptions for control flow).
-
I don't think it'll break a lot of code. (Happy to see evidence either way). It makes code like this behave the same when oci_pconnect() or oci_connect() is used (both connect calls need to be changed to matching connect or pconnect calls): <?php function f () { $c = oci_pconnect("hr", "hrpwd", "ca-tools1/orcl"); $s = oci_parse($c, "insert into t1 values (1)"); oci_execute($s, OCI_DEFAULT); // no commit // End of scope, no PHP variable references the connection after // the function returns // The transaction on a oci_pconnect is rolled back in 5.3, unless // oci8.old_oci_close_semantics=1 is used // The transaction on an oci_connect call is always rolled back in all 5.x } f(); $c = oci_pconnect("hr", "hrpwd", "ca-tools1/orcl"); oci_commit($c); // Commits unless end-of-scope already rolledback ?> This example is unchanged. There is no difference if oci_pconnect or oci_connect calls are used: <?php function f ($c) { $s = oci_parse($c, "insert into t1 values (2)"); oci_execute($s, OCI_DEFAULT); // no commit // end of function but global $c1 still holds connection open } $c1 = oci_pconnect("hr", "hrpwd", "ca-tools1/orcl"); f($c1); $c2 = oci_pconnect("hr", "hrpwd", "ca-tools1/orcl"); oci_commit($c2); // Commits the new row ?>
-
Dang that lack of preformatted text.
-
Regarding try/catch, this example has the same behavior in PHP 5.2 as with the new version of the extension in PHP 5.3. The oci8.old_oci_close_semantics setting has no impact, either. In the catch block, $c is still in scope. The semantic change mentioned in the blog post has an impact when all variables referening the connection go out of scope, which isn't the case here. <?php try { $c = oci_pconnect("hr", "hrpwd", "ca-tools1/orcl"); $s = oci_parse($c, "insert into t1 values (1)"); oci_execute($s, OCI_DEFAULT); // no commit throw new Exception; } catch (Exception $e) { echo "Caught Exception\n"; oci_commit($c); // $c is still in scope so this will commit the data } ?>
-
A question on the implicit silent rollback: Does it imply an extra trip to the database server to run the rollback? [There is an extra trip - cj]