garbage collection of open resources

[Mark Broadbent]

Everything I have read suggests that if I open files or database connections
or the like, that I should explicitly close those said resources before
making the object subject to GC. This is obviously good programming
technique.

However what happens if this practice is not followed. e.g.
that I have a base object that creates an instance of a filestream and for
arguements sake an instance of a oledb connection.
Both sub objects are opened (one to a file and one to a db) and used to
read/ write data.

Say for instance that I implement the IDisposible interface for the parent
class definition (that instanciates both objects) and within the Dispose()
method I set both object variable references to null (without closing them).
I am under the impression that they will be made available to the GC.

My question is - could data corruption occur to any open data sources that
have been made available to garbage collection OR does (as I suspect) it
simply means that those open resources (open files) will simply be locked
out until the GC destroys them?

Obviously I know that there are several reasons for closing the resources
but I would like to know that corruption is not one of them.
--

Br,
Mark Broadbent
mcdba , mcse+i
=============

[John Wood]

Eventually you might run out of resources. In this case two things could
happen:
1. When you next go to use that file, it may say that it's locked or already
open.
2. Opening a new file will might throw an exception stating that there are
too many open files.

The GC does dispose of all objects eventually, and even if you set the
reference to null and forget to close the file handle, the file stream
itself implements IDisposable and will close the file for you. Just that it
won't happen until potentially much later, leaving the option for open
handles to accumulate.

"Mark Broadbent" <no************@no-spam-please.com> wrote in message
news:u$**************@TK2MSFTNGP10.phx.gbl...

Everything I have read suggests that if I open files or database connections or the like, that I should explicitly close those said resources before
making the object subject to GC. This is obviously good programming
technique.

However what happens if this practice is not followed. e.g.
that I have a base object that creates an instance of a filestream and for
arguements sake an instance of a oledb connection.
Both sub objects are opened (one to a file and one to a db) and used to
read/ write data.

Say for instance that I implement the IDisposible interface for the parent
class definition (that instanciates both objects) and within the Dispose()
method I set both object variable references to null (without closing them). I am under the impression that they will be made available to the GC.

My question is - could data corruption occur to any open data sources that
have been made available to garbage collection OR does (as I suspect) it
simply means that those open resources (open files) will simply be locked
out until the GC destroys them?

Obviously I know that there are several reasons for closing the resources
but I would like to know that corruption is not one of them.
--

Br,
Mark Broadbent
mcdba , mcse+i
=============

[mikeb]

John Wood wrote:

Eventually you might run out of resources. In this case two things could
happen:
1. When you next go to use that file, it may say that it's locked or already
open.
2. Opening a new file will might throw an exception stating that there are
too many open files.

The GC does dispose of all objects eventually, and even if you set the
reference to null and forget to close the file handle, the file stream
itself implements IDisposable and will close the file for you. Just that it
won't happen until potentially much later, leaving the option for open
handles to accumulate.
Another thing to be aware of is that on application shutdown finalizers
are not necessarily called. So, the file close will occur (as the OS
does this on process shutdown) but any buffered data might not be
flushed to the file.

Compile and run the following with no command line arguments to see this
behavior (run with "dispose" or "close" on the command line to get the
data flushed):

//================================================== ========
using System;
using System.IO;
using System.Text;

public class MyClass
{
public static void Main(string[] args)
{
string arg = null;

if (args.Length > 0) {
arg = args[0].ToLower();
}

StreamWriter sw = new StreamWriter( @"c:\temp\swtest.out");

sw.WriteLine( "Does this data actually make it into the file?");
sw.Write( "It depends...");

if (arg != null) {
switch (arg) {
case "dispose":
((IDisposable) sw).Dispose();
break;
case "close":
sw.Close();
break;
default:
// do nothing
break;
}
}
}
}
//================================================== ========

"Mark Broadbent" <no************@no-spam-please.com> wrote in message
news:u$**************@TK2MSFTNGP10.phx.gbl...

Everything I have read suggests that if I open files or database

connections

or the like, that I should explicitly close those said resources before
making the object subject to GC. This is obviously good programming
technique.

However what happens if this practice is not followed. e.g.
that I have a base object that creates an instance of a filestream and for
arguements sake an instance of a oledb connection.
Both sub objects are opened (one to a file and one to a db) and used to
read/ write data.

Say for instance that I implement the IDisposible interface for the parent
class definition (that instanciates both objects) and within the Dispose()
method I set both object variable references to null (without closing

them).

I am under the impression that they will be made available to the GC.

My question is - could data corruption occur to any open data sources that
have been made available to garbage collection OR does (as I suspect) it
simply means that those open resources (open files) will simply be locked
out until the GC destroys them?

Obviously I know that there are several reasons for closing the resources
but I would like to know that corruption is not one of them.
--

Br,
Mark Broadbent
mcdba , mcse+i
=============

--
mikeb

[John Wood]

That's actually very interesting -- you'd think that the CLR would ask the
GC to finalize everything before it terminates... that's kind-of a bug don't
you think?

"mikeb" <ma************@nospam.mailnull.com> wrote in message
news:eE*************@TK2MSFTNGP11.phx.gbl...

John Wood wrote:

Eventually you might run out of resources. In this case two things could
happen:
1. When you next go to use that file, it may say that it's locked or already open.
2. Opening a new file will might throw an exception stating that there are too many open files.

The GC does dispose of all objects eventually, and even if you set the
reference to null and forget to close the file handle, the file stream
itself implements IDisposable and will close the file for you. Just that it won't happen until potentially much later, leaving the option for open
handles to accumulate.

Another thing to be aware of is that on application shutdown finalizers
are not necessarily called. So, the file close will occur (as the OS
does this on process shutdown) but any buffered data might not be
flushed to the file.

Compile and run the following with no command line arguments to see this
behavior (run with "dispose" or "close" on the command line to get the
data flushed):

//================================================== ========
using System;
using System.IO;
using System.Text;

public class MyClass
{
public static void Main(string[] args)
{
string arg = null;

if (args.Length > 0) {
arg = args[0].ToLower();
}

StreamWriter sw = new StreamWriter( @"c:\temp\swtest.out");

sw.WriteLine( "Does this data actually make it into the file?");
sw.Write( "It depends...");

if (arg != null) {
switch (arg) {
case "dispose":
((IDisposable) sw).Dispose();
break;
case "close":
sw.Close();
break;
default:
// do nothing
break;
}
}
}
}
//================================================== ========

"Mark Broadbent" <no************@no-spam-please.com> wrote in message
news:u$**************@TK2MSFTNGP10.phx.gbl...

Everything I have read suggests that if I open files or database

connections

or the like, that I should explicitly close those said resources before
making the object subject to GC. This is obviously good programming
technique.

However what happens if this practice is not followed. e.g.
that I have a base object that creates an instance of a filestream and forarguements sake an instance of a oledb connection.
Both sub objects are opened (one to a file and one to a db) and used to
read/ write data.

Say for instance that I implement the IDisposible interface for the parentclass definition (that instanciates both objects) and within the Dispose()method I set both object variable references to null (without closing

them).

I am under the impression that they will be made available to the GC.

My question is - could data corruption occur to any open data sources thathave been made available to garbage collection OR does (as I suspect) it
simply means that those open resources (open files) will simply be lockedout until the GC destroys them?

Obviously I know that there are several reasons for closing the resourcesbut I would like to know that corruption is not one of them.
--

Br,
Mark Broadbent
mcdba , mcse+i
=============

--
mikeb

[David Browne]

"John Wood" <[e-mail]> wrote in message
news:%2****************@TK2MSFTNGP12.phx.gbl...

That's actually very interesting -- you'd think that the CLR would ask the
GC to finalize everything before it terminates... that's kind-of a bug don't you think?

It does, there's just no guarantee. If finalizers take too long or create
too many new objects the CLR will give up and shut down the process without
finalizing all the objects.

David

[Mark Broadbent]

thx Mike/ John!

--

--

Br,
Mark Broadbent
mcdba , mcse+i
=============
"mikeb" <ma************@nospam.mailnull.com> wrote in message
news:eE*************@TK2MSFTNGP11.phx.gbl...

John Wood wrote:

Eventually you might run out of resources. In this case two things could
happen:
1. When you next go to use that file, it may say that it's locked or already open.
2. Opening a new file will might throw an exception stating that there are too many open files.

The GC does dispose of all objects eventually, and even if you set the
reference to null and forget to close the file handle, the file stream
itself implements IDisposable and will close the file for you. Just that it won't happen until potentially much later, leaving the option for open
handles to accumulate.

Another thing to be aware of is that on application shutdown finalizers
are not necessarily called. So, the file close will occur (as the OS
does this on process shutdown) but any buffered data might not be
flushed to the file.

Compile and run the following with no command line arguments to see this
behavior (run with "dispose" or "close" on the command line to get the
data flushed):

//================================================== ========
using System;
using System.IO;
using System.Text;

public class MyClass
{
public static void Main(string[] args)
{
string arg = null;

if (args.Length > 0) {
arg = args[0].ToLower();
}

StreamWriter sw = new StreamWriter( @"c:\temp\swtest.out");

sw.WriteLine( "Does this data actually make it into the file?");
sw.Write( "It depends...");

if (arg != null) {
switch (arg) {
case "dispose":
((IDisposable) sw).Dispose();
break;
case "close":
sw.Close();
break;
default:
// do nothing
break;
}
}
}
}
//================================================== ========

"Mark Broadbent" <no************@no-spam-please.com> wrote in message
news:u$**************@TK2MSFTNGP10.phx.gbl...

Everything I have read suggests that if I open files or database

connections

or the like, that I should explicitly close those said resources before
making the object subject to GC. This is obviously good programming
technique.

However what happens if this practice is not followed. e.g.
that I have a base object that creates an instance of a filestream and forarguements sake an instance of a oledb connection.
Both sub objects are opened (one to a file and one to a db) and used to
read/ write data.

Say for instance that I implement the IDisposible interface for the parentclass definition (that instanciates both objects) and within the Dispose()method I set both object variable references to null (without closing

them).

I am under the impression that they will be made available to the GC.

My question is - could data corruption occur to any open data sources thathave been made available to garbage collection OR does (as I suspect) it
simply means that those open resources (open files) will simply be lockedout until the GC destroys them?

Obviously I know that there are several reasons for closing the resourcesbut I would like to know that corruption is not one of them.
--

Br,
Mark Broadbent
mcdba , mcse+i
=============

--
mikeb

[mikeb]

David Browne wrote:

"John Wood" <[e-mail]> wrote in message
news:%2****************@TK2MSFTNGP12.phx.gbl...

That's actually very interesting -- you'd think that the CLR would ask the
GC to finalize everything before it terminates... that's kind-of a bug

don't

you think?

It does, there's just no guarantee. If finalizers take too long or create
too many new objects the CLR will give up and shut down the process without
finalizing all the objects.

While not being guaranteed is one thing, it actually *appears* to make
little or no effort. Maybe there's something in the sample that would
cause the finalization of the StreamWriter (or some other object that I
don' know about) to take too long, but I don't know what it is and if
there's any guidance about it I'd appreciate a pointer.

In practice, this means that you'd better make sure your code calls
Close() or Dispose() (either directly or via a 'using' statement) on
buffered file objects (and other resources, too, I'm sure). The
fallback that the GC will eventually take care of Disposing objects that
your code didn't handle explicitly does not seem to hold for a
significant situation (clean process termination).

Clearly, not calling Dispose() on a disposable object is a bug in the
application; however, I just wanted to point out that resource leakage
while the app is running is not the only side-effect of neglecting
Dispose() - data could be lost as well.
--
mikeb