From: Ellen K. 

I guess the new system will use connection pooling but what we have now
with our SQL Servers is the user's connection is created when s/he first
logs in, and persists until s/he logs off.  This is contrary to the
Received Wisdom but works great.

On Fri, 20 May 2005 12:59:09 +0100, "Paul Ranson"
 wrote in message :

>So your code has to check the connection before every call? How does the
>pool determine that the connection is not active?
>
>Seems like  you're leaping through hoops to avoid doing it the easy way.
>
>So why does Java not have destructors? 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...
>
>Paul
>
>"Adam Flinton"  wrote in message
>news:428ba225$1{at}w3.nls.net...
>> Paul Ranson wrote:
>>> But implementing your 'proper pooling mechanism' is far from
trivial. How
>>> does the pool know you're done with a connection? You have to tell it. A
>>> bit analagous to new/delete that. Hmm. Cue the tired
programmer syndrome.
>>> Or let the compiler use a destructor to do the work.
>>>
>>
>> Nah mate...pool has a scavenge if not active mech & your code
simply does
>> an if null getConnection before launching into some sql.
>>
>> OK so instead of a memleak the tired progger will give you a null pointer
>> error but that can be found & flush fairly fast.
>>
>>
>>> So why doesn't Java have destructors? I can't find a good reason.
>>>
>>
>> Why does a managed vm need to let the coder do that?
>>
>> Heck if you're writing native win32 c++ you're in a managed sandbox too,
>> the only diff being the sandbox is the OS.
>>
>> Adam
>

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