From: Ellen K. 

C# doesn't need it, connection pooling is automatic.

On Fri, 20 May 2005 21:39:18 +0100, "Paul Ranson"
 wrote in message :

>I think you simply don't understand the elementary construct I'm talking
>about.
>
>In C++ I can write code that I can prove closes the connection, or returns
>it to the pool, on every path and in the presence of exceptions. It's simple
>and elegant at the user level. I don't understand why Java and C# don't have
>something similar, it would be compatible with existing syntax.
>
>Paul
>
>"Adam"  wrote in message
>news:428de53c$1{at}w3.nls.net...
>> Paul Ranson wrote:
>>
>>> So your code has to check the connection before every call?
>>
>> Depends. No you don't have to. You can simply call to a pooled connection
>> & it will give you one from it's hashtable of conns when you need it.
>>
>> It's an architectural issue as you could simply use some form of ORM
>> instead (e.g. hibernate or JORM). If you want to get ambitious try:
>>
>> http://c-jdbc.objectweb.org/
>>
>> It is in C++ too given you have to write a class which instantiates the
>> conn & then closes/destructs it when the class has been
finished with. Do
>> you keep that class around & if so how does it deal with
network/db errors
>> etc i.e. re-opening dead conns? Do you create the connection everytime &
>> in a multithreaded/multi-user env do you then run out of db handles?
>>
>> Gee it sounds to me like you'd need to arch the solution dependant upon
>> the use. Gosh that sounds similar....
>>
>>> How does the pool determine that the connection is not active?
>>>
>>
>> All sorts of ways. An oft used method is to use a factory method to get a
>> conn & within the call to get the object from the factory you provide an
>> expiry time. There can be an upper limit config'ed into the pool by the
>> server admin i.e. you might set 10 minutes expiry but the server might go
>> "sod that mate you're getting 18K milliseconds tops".
>>
>>
>>> Seems like  you're leaping through hoops to avoid doing it the easy way.
>>>
>>
>> Hardly. So are you keeping your object around & what happens if the db
>> refuses/network is down/slow etc.? Having to jump through hoops in
>> designing your class to guard against such occurences or simply create a
>> new connection every time you access the db?
>>
>> Gee seems to me that you should just get a pooling mech as that's the easy
>> way.
>>
>>
>>> So why does Java not have destructors?
>>
>> You can (& should) close connections.
>>
>>> Somebody must be able to say. I think it is because the original
>>> designers hadn't considered them in any other context than memory
>>> management. And now they're stuck...
>>>
>>
>> Hardly. No reason at all why you can't deference an object & then call
>> system.gc() or indeed for something like a dbconn you can call
>> conn.close().
>>
>>
>> Adam
>

--- BBBS/NT v4.01 Flag-5