Kyley, Oh, I forgot to mention, client connections will NOT be persistent. The original application that I inherited did not work this way, and it was the first thing I identified that was greatly amiss in the design.
So, my intention is to have a client connect, make a request, get a response back from the server (which is the ONLY software that connects to the database - believe it or not, the original design had each client connecting to the database directly, and with a persistent connection - ouch!) and then drops the connection. This sound exactly as you have described. The fact that Indy creates a separate thread for each client connection sounds like half the work is done for us already. My only concern is that as Indy grants the connection request and creates the thread, then the connection to the database is created at that time and you have the overhead of the connection being made. (This time could negatively impact the server response time to the client request) Before you mentioned the way Indy handles this, I had envisioned pre-creating a pool of threads in the Delphi server application each with a connection to the database already in place (no overhead at client request time). The server is on a LAN connection to the database machine which is 5 feet away, where the clients are remote and could be anywhere in the world. In this case the server's persistent connection to the database is not necessarily that bad since it is on a LAN anyway. The server's connection to the database would be via IB Objects. And the client communications with the server would be via non-persistent sockets that are only connected for the duration of the request/response cycle. I also envision the pool of threads with their connections being a configurable number that is established during the server start up. Of course, there would be the means to create additional threads with connections for the occasional burst of connections needed (pool maxed out), if that situation arises. (But the temporary threads would be released - along with their resources once the transaction is completed). Thereby, for the most part, there would mostly be a permanent pools of threads/connections as originally configured at startup. A collection of connection statistics will provide information needed to best tune my server with the appropriate number of threads/connections at start up to maximize use of the pool, and minimize the need for 'spill-over' threads that have to be created on the fly. Also, for the pool of threads, they would have the capability to test for a valid database connection and reconnect if the connection is dropped. (I have already written code that does this for other parts of the application. My only question mark is how to connect one of the threads in the pool to each socket connection request as it is granted by the server for a given client. I did this years ago in straight C on a Unix platform where I just passed the handle of the socket connection to the new process (we used fork and exec in those days). I am hoping some similar mechanism can be used with the threads and sockets in Delphi. Thanks, Eric Eric Tishler Software Architect Resolute Partners, LLC Phone: 203.271.1122 Fax: 203.271.1460 [EMAIL PROTECTED] -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Kyley Harris Sent: Wednesday, July 21, 2004 8:27 AM To: 'NZ Borland Developers Group - Delphi List' Subject: RE: [DUG] Back with a question about good socket components Indy creates one thread per client connection. Inside that thread you then do your database work using a DB connection pool. Ie. 25 Indy Client Threads share 5 DB connections using critical section style lock and aquire techniques. There are many examples floating around of Writing a connection pooling object for databases. As far as indy goes. The secret is to not keep all your clients connected all the time. It is better to do it in a similar fashion to HTTP where each client connects for the period of doing a particular batched request and closes down again. This essentially is how you get connection pooling. You may have a 1000 clients using a GUI but if only 100 are requesting data at a time you minimise your resource use. If you keep session objects in your server for a life-time managed object based on user and IP address then each reconnection can easily be verified. > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > On Behalf Of Eric Tishler > Sent: Thursday, 22 July 2004 12:21 a.m. > To: NZ Borland Developers Group - Delphi List > Subject: RE: [DUG] Back with a question about good socket components > > Stephen, > > Your insight and experience are valuable and greatly appreciated. > > We are using Firebird 1.0.3 and IB Objects which does not have connection > pooling. But, IB Objects comes with a tutorial and example code on how to > set up thread pooling, each with its own unique connection to the database > (connection pooling of sorts). So I am left wondering if the same would > apply for Indy. That is use the thread pooling to handle each socket > connection request and subsequent messaging for that particular session. I > may be wrong, but it seems that a properly threaded application would take > load off the socket component on onto the Delphi application itself. > > Perhaps I am over simplifying in this case? > > Either way, the FPiette socket components have other inherent problems. So > I am inclined to go with Indy. > > Thank you for your input. > > Eric > > Eric Tishler > Software Architect > Resolute Partners, LLC > Phone: 203.271.1122 > Fax: 203.271.1460 > [EMAIL PROTECTED] > > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:delphi- > [EMAIL PROTECTED] On Behalf Of Stephen Bertram > Sent: Tuesday, July 20, 2004 6:19 PM > To: NZ Borland Developers Group - Delphi List > Subject: RE: [DUG] Back with a question about good socket components > > A word of warning - Indy is not totally scalable. If you read the Indy > forums there are specific warnings that it is not designed for ultra > heavy use. > > We are running into problems when we increase the connections from 500 > to over 1000. It may be that the issue is in our internal thread > handling, but we are seeing the application vanish without a trace when > under heavy load or display some other random weird symptoms. We use > database connection pooling, but we are still looking at over 400 > database connections on occasion which may be the issue. However the > main issue appears to be the lack of thread pooling in Indy - each > connection creates a dedicated thread by default. > > We are currently evaluating other TCP/IP components for this > application. > > You may never hit this level of abuse, but it has caught us out badly. > > Stephen > > > -----Original Message----- > From: Eric Tishler [mailto:[EMAIL PROTECTED] > Sent: Wednesday, 21 July 2004 7:35 a.m. > To: NZ Borland Developers Group - Delphi List > Subject: RE: [DUG] Back with a question about good socket components > > I wil have to look into Indy. We are running D6, but perhaps it is a > newer version of Indy we have. I will need to look into this further. > > In answer to your questions: > > 1) It works for the most part, but becomes unreliable under heavy loads. > (This was not designed with scalability in mind) > > 2) That would require a rewrite of complete sections of code. Besides > the architecture uses sockets for a reason, this in not a web based > application. It just happens to use the Internet as a transport > mechanism. (Not a great idea to date) > > Thanks for your response, > > Eric > > Eric Tishler > Software Architect > Resolute Partners, LLC > Phone: 203.271.1122 > Fax: 203.271.1460 > [EMAIL PROTECTED] > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Dennis Chuah > Sent: Tuesday, July 20, 2004 3:25 PM > To: NZ Borland Developers Group - Delphi List > Subject: Re: [DUG] Back with a question about good socket > components > > > Eric > > Indy - don't know which is the latest version, but we use version 9.010 > here > and it is rock solid. Open source with a large following, so you ought > to > be able to get help from discussion groups, etc. No support other than > that > though. ... and like Kylie says, good enough for Borland to include in > Delphi in preference to NetMasters, though, I wouldn't use the old > version > that came bundled with D6. > > A couple of questions I would like you to ask yourself: > > 1. The client/server product obviously works? So why change the > sockets > library? > 2. If you are going to change the sockets library, consider using HTTP > instead - you have a web server application acting as your sockets > server > and your clients communicate with it using HTTP, or SOAP over HTTP. Use > the > WinAPI Inet functions on the client and there is no need to delve into > sockets, etc. > > HTH, > Dennis. > > ----- Original Message ----- > From: "Eric Tishler" <[EMAIL PROTECTED]> > > > > Well, the forum appears to be back up up once again. So I will repeat > my > last question ... > > > > I have inherited a large scale client server system in Delphi. The > original developer was saving money and got the Freeware FPiette package > to > implement socket communication. > > > > Is there a good socket package that anyone here could recommend? This > is > something I am willing to pay for since I am looking for a package with > a > solid reputation that includes technical support. > > > > I need this for Delphi 6. > > > > Good to be back, > > > > Eric > > > > _______________________________________________ > > Delphi mailing list > > [EMAIL PROTECTED] > > http://ns3.123.co.nz/mailman/listinfo/delphi > > > _______________________________________________ > Delphi mailing list > [EMAIL PROTECTED] > http://ns3.123.co.nz/mailman/listinfo/delphi > > > > _______________________________________________ > Delphi mailing list > [EMAIL PROTECTED] > http://ns3.123.co.nz/mailman/listinfo/delphi > > Disclaimer : This communication contains information that is confidential > and the copyright of ensynergy Limited or a third party. If you are not > the intended recipient of this communication please delete and destroy all > copies and telephone ensynergy Limited on +64 9 3551591 immediately. If > you are the intended recipient of this communication you should not copy, > disclose or distribute this communication without the authority of > ensynergy Limited. Any views expressed in this communication are those of > the individual sender, except where the sender specifically states them to > be the views of ensynergy Limited. Except as required by law, ensynergy > Limited does not represent, warrant and/or guarantee that the integrity of > this communication has been maintained nor that the communication is free > of errors, virus, interception or interference. > > > _______________________________________________ > Delphi mailing list > [EMAIL PROTECTED] > http://ns3.123.co.nz/mailman/listinfo/delphi > > > > _______________________________________________ > Delphi mailing list > [EMAIL PROTECTED] > http://ns3.123.co.nz/mailman/listinfo/delphi _______________________________________________ Delphi mailing list [EMAIL PROTECTED] http://ns3.123.co.nz/mailman/listinfo/delphi _______________________________________________ Delphi mailing list [EMAIL PROTECTED] http://ns3.123.co.nz/mailman/listinfo/delphi
