Re: PEAR shutdown function doesn't rollback transactions

Hi, Seems pretty inconsistent. It depends on your database extension: A quick check of the oci8 source code for php 4.2.0 reveals that cleaning and freeing statements code is there, but has been commented out. PHP_RSHUTDOWN_FUNCTION(oci) { oci_debug("START php_rshutdown_oci"); #if 0 /* XXX free all statements, rollback all outstanding transactions */ zend_hash_apply(OCI(user), (apply_func_t) _session_cleanup TSRMLS_CC); zend_hash_apply(OCI(server), (apply_func_t) _server_cleanup TSRMLS_CC); #endif oci_debug("END php_rshutdown_oci"); return SUCCESS; } In contrast, pgsql does clean up transactions: PHP_RSHUTDOWN_FUNCTION(pgsql) { if (PGG(last_notice)) { efree(PGG(last_notice)); } zend_hash_apply(&EG(persistent_list), (apply_func_t) _rollback_transactions TSRMLS_CC); return SUCCESS; } While mysql doesn't do much: PHP_RSHUTDOWN_FUNCTION(mysql) { if (MySG(connect_error)!=NULL) { efree(MySG(connect_error)); } return SUCCESS; } Perhaps someone can explain further... Regards, John "Bas" <post@bushbaby.nl> wrote in message news:B94F72B5.CA52%post@bushbaby.nl... > Hi, I'm using PEAR to start transaction for database conections. While > reading in to this I saw the warning issued on the page below... > > Now I saw that the registered PEAR shutdown function does not include any > rollback functionality... Is this something that should be done in future > releases? I noticed that the PEAR class does record the number of > transactions started... > > Or am I missing the point entirely and should I implement something in my > own classes. (keep track of if any transactions have started and shutting > them down if they were not rollback or commited. > > Alternatively I could use non persistent db connection... > > > Thx for any thoughts. > > Bas > > > http://www.php.net/manual/en/features.persistent-connections.php > > "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 canuse > 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)." > > > > >