I like the analogy :) One thing though is that Jenson's solution (which is only one I know) does not require you to return the connection. It uses interfaces. Matt.
> Phil > > Yes, For cute points you get ConnectionFish out of the > ConnectionPool and is they don't go back into the ConnectionPool > they Die > > These systems are popular because Oracle had such a long connection > time, so it really depends on the DB you are using, for most systems > this is unnecesary depends how many simultaneous connections you > envisage and the lic schemeof your db > > N > > > > Matthew Comb wrote: >> Hey Phil, not sure how much you want to engineer this, but an approach >> would be a connection pool. >> >> Main advantages being that the main overhead with a connection is the >> opening and closing of it. A connection pool can keep the connections >> open >> as they belong to the pool and your tcpthreads can reuse the >> connections. >> You need some logic to block the use of your connection by only one >> thread >> at a time and some cleanup logic on the connections should they die or >> timeout. >> >> Heres a useful article from one of the borland guys. Carey Jenson I >> think ? >> >> http://bdn.borland.com/article/0,1410,30027,00.html >> >> Regards, >> >> Matt. >> >> >>> Okay, I have TCPServer servicing multiple clients. I want to add some >>> information flows that would require the TCPServer to access single >>> records that are stored in a database (accessed via ADO). My >>> initial thought is to make the ADO objects global to the service and >>> use >>> critical sections to control TCPServer threads accessing data from >>> ADO >>> objects. Each transaction is a single record read only to database so >>> shouldn't be too tricky?? >>> >>> Alternative would be for each TCPServer thread to have own ADO >>> object and each one make their own connection to the database. This >>> seems more memory intensive and raising question of whether ADO >>> objects are thread-safe anyway. >>> >>> Thoughts anyone?? >>> >>> ---------------------------------------------------------- >>> Phil Scadden, Institute of Geological and Nuclear Sciences >>> 764 Cumberland St, Private Bag 1930, Dunedin, New Zealand >>> Ph +64 3 4799663, fax +64 3 477 5232 >>> >>> _______________________________________________ >>> 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 >> >> > > -- > Neven MacEwan (B.E. E&E) > Ph. 09 620 1356 Mob. 027 4749 062 > > New Address Details > =================== > MWK Computer Systems > 1 Taumata Rd > Sandringham > Auckland > > Ph 620 1356 > Fx 620 1336_______________________________________________ > 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
