That's not true. You can have one persistant connection and reuse that for all requests, it'll just take away from having to connect/disconnect all the time. No one said you have to open 40 different connections and pay for 40 concurrent licenses.
> -----Original Message----- > From: Terry Maragakis [mailto:[EMAIL PROTECTED] > Sent: Wednesday, June 30, 2004 12:42 PM > To: Tim Bunce; Dave Mullen - Marikina CGI > Cc: [EMAIL PROTECTED] > Subject: RE: DBI Module. > > > 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. >
