[DUG] Access to Database from TCPServer threads

[Matthew Comb]

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
>>> Delphi at ns3.123.co.nz
>>> http://ns3.123.co.nz/mailman/listinfo/delphi
>>>
>>
>>
>> _______________________________________________
>> Delphi mailing list
>> Delphi at ns3.123.co.nz
>> 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
> Delphi at ns3.123.co.nz
> http://ns3.123.co.nz/mailman/listinfo/delphi