Mr Bunce, Not all of the rest of the world is using persistent database connections.
There is a good reason not to use persistent database connections, it is database licensing. Licensing may not be an issue with mysql but it is an issue with commercial databases. I use Informix with hundreds of users accessing the database for extremely short queries from a GUI. I cannot afford to have them connected constantly, I would have to spent $100,000 per server in licensing. Having them connect and disconnect for every query has cost me about $3,000 per server using concurrent user licensing. Even in the case of mysql you can have applications (web access to a database for example) that can only be implemented with non persistent connections. I have not experienced any connection delays like Mr Mullen describes, as a matter of fact I am very satisfied with the connection times (they average less than 1ms on a 2.4GHz dual CPU Xeon on Linux) but I do have a problem with the discconnect statements, they consistently take about 1 second. This is generaly not an issue since the users have to proccess the information after it is returned to them on the GUI but I occasionaly get a complaint. Connect/disconnect times are important and they should be given due consideration. By the way, since this is my first posting to this group I would like to thank you for all your work on the Perl database interfaces, they are extremely valuable tools. Thanks, Terry Maragakis Database Administrator The Inteq Group Inc. 5445 La Sierra Dr. Suite 400 Dallas, TX 75231 214-739-9494 214-739-7979 Fax [EMAIL PROTECTED] www.inteqrx.com ____________________________________________________________________________________________ IMPORTANT: This message is intended only for the use of the individual or entity to which it is addressed and may contain information that is privileged, confidential and exempt from disclosure under federal or state law. If you received this communication in error, please destroy and notify the sender by return message or call our Privacy Administrator at 800-324-7799. -----Original Message----- From: Tim Bunce [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 30, 2004 10:27 AM To: Dave Mullen - Marikina CGI Cc: [EMAIL PROTECTED] Subject: Re: DBI Module. On Wed, Jun 30, 2004 at 03:19:15PM +0200, Dave Mullen - Marikina CGI wrote: > Dear Mr Bunce, > > We are using perl 5.005 and mysql 3.23 on a Linux Redhat 7.2 system. > > We are trying to implement a better "timeout" for the DBI connections, as > the one incorporated in the DBI module only has a granularity of seconds. > > We don't use persistent connections or mod-perl, so connection time is an > important factor for us, and we wish to avoid excessive times, as this > affects our server performance. So why not use persistent connections or mod-perl like the rest of the world? > Herewith is the test script, which basically wraps the connection in an eval > block, and the Time::HiRes "alarm" will cause the eval to die after 10ms. > This script perfomed well over a 24 hour period, our only concern is that > sometimes we recorded the following error message during the "eval cleanup" > > (in cleanup) dbih_getcom handle DBI::db=HASH(0x8258a28) is not a DBI handle > (has no magic) > > Obviously, the alarm triggers and the eval block dies at some point during > the creation of the DBI object, our concern is that this "eval cleanup > failure" may be leaving resources behind on the system ??? Probably. > Your comments please. Don't do it. Honestly. It's not reliable and can't be made reliable. Search the web for discussions of perl and signals. Even if you got it to work (and appear reliable) it'll probably break when you upgrade perl to a later one that has "safe signals". Here be dragons. The rest of the world uses persistent connections or mod-perl for a reason. Tim.
