I am actually quite satisfied with the IBM Informix workgroup server licensing scheme. I also considered Oracle but their choices of CPU or named user licensing (they do not offer concurrent licensing) made it very expensive. It is interesting that DB2, the flagship IBM database product has removed the ability from the license to use the DB2 workgroup server for web based connections.
I am also very happy with the new connection times from Perl to the Informix database. I wish that the disconnect times would be as efficient. My main point was that there may be a legitimate reasons for not using persistent connections and connecting/disconnecting to the database performance should be given due consideration. 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 12:22 PM To: Terry Maragakis; Tim Bunce; Dave Mullen - Marikina CGI Cc: [EMAIL PROTECTED] Subject: RE: DBI Module. No, no arguments. Informix is the exact database we ran into problems with. We're were trying to resell it a few months ago and when we contacted the account reps, they had no idea of a clear definition. By the end of the conversation they basically said, go do what you want, but if we later feel that you're abusing the license, we'll let you know. Of course this won't fly in any large public company where the reputation, media, and legal actions are an issue, where a small company might take the risk. Ilya > -----Original Message----- > From: Terry Maragakis [mailto:[EMAIL PROTECTED] > Sent: Wednesday, June 30, 2004 1:16 PM > To: Sterin, Ilya (I.); Tim Bunce; Dave Mullen - Marikina CGI > Cc: [EMAIL PROTECTED] > Subject: RE: DBI Module. > > > I agree with you, that there has been a lot of confusion in > the past and that the sales people are generally uninformed > about the licensing of their products, and different vendors > may license products differently. I believe that Oracle does > not license their product on the concurent user model at all. > However, this clearly changed for Informix lincensing with > the release of the 9.40 version of the server, this was the > first time that I saw this case addressed directly. It is > clearly stated that users cannot use a shared connection to > connect to the database. I specifically questioned this > during a session on licensing at the last IBM data management > conference and the IBM people were very clear in their > answers. They will only allow CPU licensing if you want to > use shared connections. You may argue your case but I do not > believe that it would pass an audit. > > 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:54 AM > To: Terry Maragakis; Tim Bunce; Dave Mullen - Marikina CGI > Cc: [EMAIL PROTECTED] > Subject: RE: DBI Module. > > > What connection pooling? You have one open database > connection and the rest of the scripts wait for it? There is > no concurrent access happening. The only thing that might > matter is if you're using threads and/or processes. Each db > vendor has different concurrent license schemes, I always > found it very annoying, as they themselves don't know a clear > definition of it, just ask any sales person at that company, > but they basically leave it open so that they can charge > large enterprises more by furnishing them a different > definition of the license each time it suites their needs. > > > > > -----Original Message----- > > From: Terry Maragakis [mailto:[EMAIL PROTECTED] > > Sent: Wednesday, June 30, 2004 12:50 PM > > To: Sterin, Ilya (I.); Tim Bunce; Dave Mullen - Marikina CGI > > Cc: [EMAIL PROTECTED] > > Subject: RE: DBI Module. > > > > > > 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. > > > > > >
