Re: cvs: pear /MDB2 package.php

Hello, On 11/25/2004 08:52 PM, Lukas Smith wrote:

+- removed destructor since most RDBMS handle uncommited transaction themselves

RDBMS (the server) would really rollback uncommitted transactions if the clients would have closed the connection. However, when you use persistent connections the RDBMS have no way of knowing that the PHP has exited the script unless the client (Web server process or CGI) exits making the database connection implicitly die. Therefore it seems you are making a big mistake because this feature was not added originally to Metabase for no reason. Dropping this feature will eventually lead to database havoc (read neverending deadlocks), which is what this Metabase feature was intended to solve.

thats a good point. i am just not sure how many people are really affected by this ... especially since handling things yourself is quite

Duh? how many people are affected by this?!? The way I see it, either you design software that is robust or you don't. This feature was added to Metabase to make it more robust in handling transactions with applications that use persistent connections. I think that using transactions and persistent connections is very common these days. Even if it wasn't, the software must work properly in all cases.

straightforward .. just check the "in_transaction" property yourself.

You are assuming that PHP page requests always end normally. You must not forget that for reasons that transcend the capabilities of any bug free software developer, a PHP script may exit with a fatal error, like for instance a unexpected script timeout. However, real world scripts may have bugs. So, the chances of having them exit in the middle of a transaction due to a bug that make them exit due to a fatal runtime PHP error, are even greater. Register one shutdown function is the solution for that.

especially on php4 registering a shutdown_function is not that cheap since I have to emulate true desctructors (altough people might not like destructors with persistant connections anyways) there.

It seems you are very confused. What is not so cheap in registering shutdown functions? It is just an entry in an array. I suppose you are thinking that registering a shutdown function for every single object you create on a script just like the PEAR base classes do for emulating class destructors is expensive because you may have many objects. However, this is not about emulating destructors but in fact just registering a shutdown function only once to rollback any pending transactions. That is what Metabase does. Even if you have opened many database connections in the same script, it only calls one and only one shutdown function per script. If you have changed Metabase implementation for MDB, now that is a problem that you have to sort out. It seems you keep changing Metabase original implementation on things that you quite do not understand, basically fixing things that were not broken, and I am afraid that you will be always running into problems and complaints that did not occur with Metabase. I think it would be wiser if you just focused on adding things that are missing in MDB, instead of changing or removing things that were working as intended.

however i must admit I am a bit confused about the current state in regards to persistant connections .. they seem to create alot of issues but obviously stand to improve performance considerably.

Persistent connections are just never closed. Therefore you must not forget that any pending transactions and not committed nor roll back. If they are left pending, the next Web server request that picks the same process will carry on any pending transactions and that may run forever until that process dies. -- Regards, Manuel Lemos PHP Classes - Free ready to use OOP components written in PHP http://www.phpclasses.org/ PHP Reviews - Reviews of PHP books and other products http://www.phpclasses.org/reviews/ Metastorage - Data object relational mapping layer generator http://www.meta-language.net/metastorage.html