2

In many cases when working with different types of data objects it's important to dispose of them to make sure that they don't leave a database connection open. However, table adapters don't seem vulnerable to this problem because they are built on the principle of disconnected data. I am under the impression that a table adapter will always close it's connection after the atomic Fill or Update method has completed, even in the presence of exceptions. Is this correct?

On the other hand, table adapters do implement IDisposable, so there must be some unmanaged resources to clean up at some point, right? Or is this just ceremony so that people can write:

using(var a = new MyTableTableAdapter())
{
    a.Fill(ds.MyTable);
}

and not have to think about this topic?

Paul Keister
  • 12,851
  • 5
  • 46
  • 75

1 Answers1

3

If it implements IDisposable it either currently holds resources to dispose of or may in the future. If it's disposable, you should dispose it. It's not for you to understand it's internals - only to understand it's contract and honor it. Typically, folks don't do things out of ceremony - "using" is cool syntactical sugar but not cool enough to start sprinkling IDisposable around classes that don't have resource to dispose of :)

Also, IDisposable doesn't necessarily mean "unmanaged" resources. It means there are resources (like file handles, network connections etc...) that are not objects that are garbage collected (memory). The distinction is cleaning up something not collected - not unmanaged. It just so happens that often many of those resources are backed by unmanaged OS resources.

EDIT:

For example, let's say I created a completely managed object that retrieved some other objects from a pool (cache) on demand and when you're done using it, I want it to put those objects back into the shared pool (not freed - an explicit call to add something to a pool. Nothing unmanaged here but I could pull objects from the pool on demand and in dispose I could put them back (Pool.Add) for others to use. You the consumer would simply "use" my object and know it will clean up when disposed. The explicit dispose is needed because we shouldn't wait for finalize (it may happen way later or not at all) –

bryanmac
  • 38,941
  • 11
  • 91
  • 99
  • Aren't file handles and network connections unmanaged? Here's a quote from the latest docs: "The primary use of this interface is to release unmanaged resources." see http://msdn.microsoft.com/en-us/library/system.idisposable.aspx – Paul Keister Feb 09 '12 at 01:57
  • The reason that interface was created was to "clean up" because garbage collection was meant to collect object/memory. As I said, those objects are often backed by OS resources which are ultimately unmanaged - but realize everyone is saying "Primary" and "Often". Ultimatly, it's to dispose of things when you're done - clean up. – bryanmac Feb 09 '12 at 02:07
  • For example, let's say I created a completely managed object that retrieved some other objects from a pool and when you're done using it, I want it to put those objects back into the shared pool (not freed - an explicit call to add something to a pool. Nothing unmanaged here but I could pull objects from the pool on demand and in dispose I could put them back (Pool.Add) for others to use. You the consumer would simply "use" my object and know it will clean up when disposed. The explicit dispose is needed because we shouldn't wait for finalize (it may happen way later or not at all) – bryanmac Feb 09 '12 at 02:14
  • I can't argue with the "if it's implemented, you must call it" rule. I suppose this questions is actually a criticism of the SqlDataAdapter interface, and as such is probably off-topic. – Paul Keister Feb 09 '12 at 06:24