Yes, it is true. The licensing agreement clearly states that connection pooling like you describe is not allowed under the concurrent licensing structure.
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: Sterin, Ilya (I.) [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 30, 2004 11:46 AM To: Terry Maragakis; Tim Bunce; Dave Mullen - Marikina CGI Cc: [EMAIL PROTECTED] Subject: RE: DBI Module. 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. >
