Having MS manage the connection = resource leak?
I don't follow you -- how is closing a connection (and it not being really
closed on the server end) sloppy programming? Unless you're refering the MS
programming?
Forcing developers to perform connection management does OPEN the door for
sloppy programming (a door in which we should have the option to keep
closed) -- yes I agree with that and exactly why MS should provide an option
to deal with it automatically and efficiently -- rather than the
inconsistant approach they use now.
Rather than the current method to try to close a connection:
close the datareader
close the connection
loop thru connectionstate to ensure it gets closed or timesout
dispose of the connection
and for good measure set it to Nothing
and if you're really thorough, then initial GS (garbage collection)
Then and only then, can you be pretty sure your connection is closed.
That's a LOT of work to ensure a connection gets closed -- and since it is
recommended to close connections ASAP, the developer's are encouraged to
open/close many many many times -- opening a closing connections A LOT is
also not efficient.
Rob.
"Joerg Jooss" <ne********@joergjooss.de> wrote in message
news:xn****************@msnews.microsoft.com...
Rob R. Ainscough wrote:
Peter,
But the problem with ADO.NET is that closing a connection (even
explicitly) may not immediately close the connection (you can see
this in real time at the server side). But then again, a more
serious problem IMHO is that developers have to deal with connection
state at all -- cause as you said it is now a black box that we
"think" we have control over, but in reality we "partially" have some
control but not the final control.
I wish MS would offer those of us that are NOT interested in
connection management at least an alternative
[...]
That basically translates to sloppy programming that produces resource
leaks.
Sorry.
--
http://www.joergjooss.de
mailto:ne********@joergjooss.de