Re: Re: cvs: pear /MDB2 package.php
| From: | Lukas Smith | Date: | Sat, 27 Nov 2004 17:35:56 +0000 |
| Subject: | Re: Re: cvs: pear /MDB2 package.php | ||
| References: | 1 2 3 4 | Groups: | php.pear.dev |
| Request: | Send a blank email to pear-dev+get-34604@lists.php.net to get a copy of this message | ||
Manuel Lemos wrote:
On 11/25/2004 08:52 PM, Lukas Smith wrote:Recent benchmarks by Greg indicated that the first call to register showdown brings a significant overheadIt seems you are very confused. What is not so cheap in registering shutdown functions? It is just an entry in an array.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.+- removed destructor since most RDBMS handle uncommited transaction themselves
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.Actually Greg has fixed all of theses issues, so this was not my concern.
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.Ok thats true using emulated destructors this is not the case for PEAR. However what I did before I removed the method was only to enable the destructor emulation for those instances that actually created a transaction. However I could just as well then only register the shutdown method like in Metabase to reduce the overhead even more.
Yup ok. Did you see my other mail? So basically it seems that I should probably not use emulated destructors for PHP4. Instead for PHP4 I will register a shutdown function that cycles across the global instance array upon opening the first transaction. For PHO5 I will do this via a native destructor. In that destructor I will also close any open non persistant connections to allow freeing of ressources as early as possible (since a script could go on for quite a bit after that). This could not be achieved with emulated destructors anyways. regards, Lukas Smith smith@backendmedia.com _______________________________ BackendMedia www.backendmedia.com berlin@backendmedia.com Linn Zwoch Smith GbR Pariser Str. 44 D-10707 Berlin Tel +49 30 83 22 50 00 Fax +49 30 83 22 50 07however 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.