"David Browne" <davidbaxterbrowne no potted meat@hotmail.com> wrote in
message news:edrWr7iGHHA.320@TK2MSFTNGP06.phx.gbl...
[quoted text, click to view] >
>
> "Brad Wood" <dude@sweet.com> wrote in message
> news:el0N$XhGHHA.3468@TK2MSFTNGP04.phx.gbl...
>>I have a persistence class with one dababase connection and no other
>>member objects that need management. For reasons that are not necessary
>>to go into, I'd rather not implement Dispose in this class. If I
>>implement a finalizer, and close my database connection there, I see only
>>one problem, i.e., there is a slight performance loss due to finalization
>>queue issues.
>>
>> - I don't think the perf issue matters due to the fact that I never
>> create more than one of these persistence objects.
>> - The database connection won't close quite as quickly, and will be
>> closed from a separate thread, but so what? It does close...
>>
>
> First, you should implement IDisposable. Whatever reasons you have that
> you don't want to go into, you should get over them and implement
> IDisposable.
I agree. Even if you decide not to call Dispose on your object, implement
IDisposable to give yourself the flexibility later.
[quoted text, click to view] >
> Second, don't use a Finalizer. The database connection has a finalizer
> already.
The reason is that if your finalizer calls the database's Dispose, you will
cause the database to be resurrected and its memory won't be freed until the
next GC pass. Even worse, the database could have been finalized already,
and calling any method (even Dispose) on an object after its finalizer has
run is very bad.
[quoted text, click to view] >
> Third, your question really is: "Is is alright for my application to leak
> a few database connections?" The answer is yes, so long as you only leak
> one connection, you should be fine, although it's still very bad design.
> But if the usage or design of your app changes, and you start leaking more
> database connections, your application will eventually and unpredictably
> fail.
>
> David
>
>