469,923 Members | 1,458 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,923 developers. It's quick & easy.

How can I make sure all unmanaged resources had been released ?

for example: SqlConnection is used in my project, how can I know if all
connections were closed after open and execution. If some guys forget to
close connections after using, how can i check it out ?
best,
eric

Nov 16 '05 #1
6 1620
Eric,

The System.Data.SqlClient library is a pure .Net client interface to the
database. Therefore if the connection is not closed, there is the timeout
and garbage collector to sort it out if someone doesn't do the job of
closing it down manually.

What type of unmanaged resources are you refering too?

If the managed code is hooked into native code via the Interop's, then the
garbage collector will again call the destructors on your unmanaged code
when it thinks you're finished with them during a clear up.

Therefore if the unmanaged code is not desroying its objects, the garbage
collector destroy these uncleared objects either as the onus lies with the
unmanaged resource and not the .Net application.
"Eric" <wa**********@msn.com> wrote in message
news:%2****************@TK2MSFTNGP12.phx.gbl...
for example: SqlConnection is used in my project, how can I know if all
connections were closed after open and execution. If some guys forget to
close connections after using, how can i check it out ?
best,
eric

Nov 16 '05 #2
Thank you for your reply.

SqlClient.SqlConnection should manually call Close() or Dispose() after
using. MSDN point out this. If we didn't call Close() or Dispose() manually,
SqlConnecont won't be closed when the connection object is out of range, GC
would close the connection object in some magic time. That means, if we
don't call Close() or Dispose() as soon as possible, the connection_pool
would be exhausted.

What's the worse, the connection_pool is organized by *process* and
*ConnectionString*. This means diffrent modules in one program, would share
a same connection_pool. If one connection_pool was exhausted, we can not
even find out which module cause this problem. In a huge project, this will
be a very troublesome problem, I think.


"Dan =o)" <danielbass [at] postmaster [dot] co [dot] uk> 写入邮件
news:ub*************@TK2MSFTNGP11.phx.gbl...
Eric,

The System.Data.SqlClient library is a pure .Net client interface to the
database. Therefore if the connection is not closed, there is the timeout
and garbage collector to sort it out if someone doesn't do the job of
closing it down manually.

What type of unmanaged resources are you refering too?

If the managed code is hooked into native code via the Interop's, then the
garbage collector will again call the destructors on your unmanaged code
when it thinks you're finished with them during a clear up.

Therefore if the unmanaged code is not desroying its objects, the garbage
collector destroy these uncleared objects either as the onus lies with the
unmanaged resource and not the .Net application.
"Eric" <wa**********@msn.com> wrote in message
news:%2****************@TK2MSFTNGP12.phx.gbl...
for example: SqlConnection is used in my project, how can I know if all
connections were closed after open and execution. If some guys forget to
close connections after using, how can i check it out ?
best,
eric


Nov 16 '05 #3
Firstly, I'm not sure why this is a problem... The pooling technique is
offered as a default so that the overhead is kept down when two connections
"appear" to be the same in the same process. This saves memory and resources
in general. If the connection times out because the "Connection Lifttime"
has expired, the the GC removes the pool from memory...

It's not a case of should, you "must" call Close()/Dispose()... Although
it's not as imperative as, calling "Open()" say, the fact is, failing to
call close leaves this connection wide open, and if you've numerous
different open connections, this in itself saps system resources.

Surely a simply find in the solution on "Open()" will give you an immediate
listing of all the instances where a connection is established?

Finally, you can turn pooling off by passing in "Pooling=false" in the
connection string. This would mean every new connection that is created is
set up as a seperate connection, regardless if one (or hundred) just like it
have already been used.

http://msdn.microsoft.com/library/de...taprovider.asp

If you employ proper connection maintenance from the start, it won't be a
problem...
"Eric" <wa**********@msn.com> wrote in message
news:uZ**************@TK2MSFTNGP09.phx.gbl...
Thank you for your reply.

SqlClient.SqlConnection should manually call Close() or Dispose() after
using. MSDN point out this. If we didn't call Close() or Dispose()
manually,
SqlConnecont won't be closed when the connection object is out of range,
GC
would close the connection object in some magic time. That means, if we
don't call Close() or Dispose() as soon as possible, the connection_pool
would be exhausted.

What's the worse, the connection_pool is organized by *process* and
*ConnectionString*. This means diffrent modules in one program, would
share
a same connection_pool. If one connection_pool was exhausted, we can not
even find out which module cause this problem. In a huge project, this
will
be a very troublesome problem, I think.


"Dan =o)" <danielbass [at] postmaster [dot] co [dot] uk> 写入邮件
news:ub*************@TK2MSFTNGP11.phx.gbl...
Eric,

The System.Data.SqlClient library is a pure .Net client interface to the
database. Therefore if the connection is not closed, there is the timeout
and garbage collector to sort it out if someone doesn't do the job of
closing it down manually.

What type of unmanaged resources are you refering too?

If the managed code is hooked into native code via the Interop's, then
the
garbage collector will again call the destructors on your unmanaged code
when it thinks you're finished with them during a clear up.

Therefore if the unmanaged code is not desroying its objects, the garbage
collector destroy these uncleared objects either as the onus lies with
the
unmanaged resource and not the .Net application.
"Eric" <wa**********@msn.com> wrote in message
news:%2****************@TK2MSFTNGP12.phx.gbl...
> for example: SqlConnection is used in my project, how can I know if all
> connections were closed after open and execution. If some guys forget
> to
> close connections after using, how can i check it out ?
>
>
> best,
> eric
>
>
>



Nov 16 '05 #4
Let's have a test to find out what would happen, if we don't manually call
Dispose() or such like that :
using System;
using System.Data;
using System.Data.SqlClient;
using System.Windows.Forms;

namespace PureTest
{
public class Class1
{
public Class1()
{
}

[STAThread]
static void Main()
{
while(true)
{
int i = 0;
try
{
for(i = 0; i < 1000; i++)
{
SqlConnection con = new
SqlConnection("server=ERIC;uid=eric;pwd=eric;datab ase=settlement");
con.Open();
}
}
catch(Exception ee)
{
MessageBox.Show("count=" + i.ToString() + "\r\n");

if(MessageBox.Show(ee.Message + "\r\n\r\ncontinue?", "connect fail",
MessageBoxButtons.YesNo) == DialogResult.No)
{
break;
}

}
}
}
}
}
We will see that connection_pool keep exhausted. This sample looks stupid,
but similar situation can really happen in a complex project.

Not_using connection pool, I don't think this is a good idea. Connecting is
an expensive operation, and Real_Connection to SQLServer is also limited.

best,
eric


"Dan =o)" <danielbass [at] postmaster [dot] co [dot] uk> 写入邮件
news:OB**************@TK2MSFTNGP12.phx.gbl...
Firstly, I'm not sure why this is a problem... The pooling technique is
offered as a default so that the overhead is kept down when two connections "appear" to be the same in the same process. This saves memory and resources in general. If the connection times out because the "Connection Lifttime"
has expired, the the GC removes the pool from memory...

It's not a case of should, you "must" call Close()/Dispose()... Although
it's not as imperative as, calling "Open()" say, the fact is, failing to
call close leaves this connection wide open, and if you've numerous
different open connections, this in itself saps system resources.

Surely a simply find in the solution on "Open()" will give you an immediate listing of all the instances where a connection is established?

Finally, you can turn pooling off by passing in "Pooling=false" in the
connection string. This would mean every new connection that is created is
set up as a seperate connection, regardless if one (or hundred) just like it have already been used.

http://msdn.microsoft.com/library/de...taprovider.asp
If you employ proper connection maintenance from the start, it won't be a
problem...
"Eric" <wa**********@msn.com> wrote in message
news:uZ**************@TK2MSFTNGP09.phx.gbl...
Thank you for your reply.

SqlClient.SqlConnection should manually call Close() or Dispose() after
using. MSDN point out this. If we didn't call Close() or Dispose()
manually,
SqlConnecont won't be closed when the connection object is out of range,
GC
would close the connection object in some magic time. That means, if we
don't call Close() or Dispose() as soon as possible, the connection_pool
would be exhausted.

What's the worse, the connection_pool is organized by *process* and
*ConnectionString*. This means diffrent modules in one program, would
share
a same connection_pool. If one connection_pool was exhausted, we can not
even find out which module cause this problem. In a huge project, this
will
be a very troublesome problem, I think.


"Dan =o)" <danielbass [at] postmaster [dot] co [dot] uk> 写入邮件
news:ub*************@TK2MSFTNGP11.phx.gbl...
Eric,

The System.Data.SqlClient library is a pure .Net client interface to the database. Therefore if the connection is not closed, there is the timeout and garbage collector to sort it out if someone doesn't do the job of
closing it down manually.

What type of unmanaged resources are you refering too?

If the managed code is hooked into native code via the Interop's, then
the
garbage collector will again call the destructors on your unmanaged code when it thinks you're finished with them during a clear up.

Therefore if the unmanaged code is not desroying its objects, the garbage collector destroy these uncleared objects either as the onus lies with
the
unmanaged resource and not the .Net application.
"Eric" <wa**********@msn.com> wrote in message
news:%2****************@TK2MSFTNGP12.phx.gbl...
> for example: SqlConnection is used in my project, how can I know if all > connections were closed after open and execution. If some guys forget
> to
> close connections after using, how can i check it out ?
>
>
> best,
> eric
>
>
>



Nov 16 '05 #5
Eric,

Like I said, it's not right if you don't call close, I don't really see what
other option you have on a large scale project. If you have the source, then
a simply match on Open/Close calls will do.

"Eric" <wa**********@msn.com> wrote in message
news:%2****************@TK2MSFTNGP11.phx.gbl...
Let's have a test to find out what would happen, if we don't manually call
Dispose() or such like that :
using System;
using System.Data;
using System.Data.SqlClient;
using System.Windows.Forms;

namespace PureTest
{
public class Class1
{
public Class1()
{
}

[STAThread]
static void Main()
{
while(true)
{
int i = 0;
try
{
for(i = 0; i < 1000; i++)
{
SqlConnection con = new
SqlConnection("server=ERIC;uid=eric;pwd=eric;datab ase=settlement");
con.Open();
}
}
catch(Exception ee)
{
MessageBox.Show("count=" + i.ToString() + "\r\n");

if(MessageBox.Show(ee.Message + "\r\n\r\ncontinue?", "connect fail",
MessageBoxButtons.YesNo) == DialogResult.No)
{
break;
}

}
}
}
}
}
We will see that connection_pool keep exhausted. This sample looks stupid,
but similar situation can really happen in a complex project.

Not_using connection pool, I don't think this is a good idea. Connecting
is
an expensive operation, and Real_Connection to SQLServer is also limited.

best,
eric


"Dan =o)" <danielbass [at] postmaster [dot] co [dot] uk> 写入邮件
news:OB**************@TK2MSFTNGP12.phx.gbl...
Firstly, I'm not sure why this is a problem... The pooling technique is
offered as a default so that the overhead is kept down when two

connections
"appear" to be the same in the same process. This saves memory and

resources
in general. If the connection times out because the "Connection Lifttime"
has expired, the the GC removes the pool from memory...

It's not a case of should, you "must" call Close()/Dispose()... Although
it's not as imperative as, calling "Open()" say, the fact is, failing to
call close leaves this connection wide open, and if you've numerous
different open connections, this in itself saps system resources.

Surely a simply find in the solution on "Open()" will give you an

immediate
listing of all the instances where a connection is established?

Finally, you can turn pooling off by passing in "Pooling=false" in the
connection string. This would mean every new connection that is created
is
set up as a seperate connection, regardless if one (or hundred) just like

it
have already been used.

http://msdn.microsoft.com/library/de...taprovider.asp

If you employ proper connection maintenance from the start, it won't be a
problem...
"Eric" <wa**********@msn.com> wrote in message
news:uZ**************@TK2MSFTNGP09.phx.gbl...
> Thank you for your reply.
>
> SqlClient.SqlConnection should manually call Close() or Dispose() after
> using. MSDN point out this. If we didn't call Close() or Dispose()
> manually,
> SqlConnecont won't be closed when the connection object is out of
> range,
> GC
> would close the connection object in some magic time. That means, if we
> don't call Close() or Dispose() as soon as possible, the
> connection_pool
> would be exhausted.
>
> What's the worse, the connection_pool is organized by *process* and
> *ConnectionString*. This means diffrent modules in one program, would
> share
> a same connection_pool. If one connection_pool was exhausted, we can
> not
> even find out which module cause this problem. In a huge project, this
> will
> be a very troublesome problem, I think.
>
>
>
>
> "Dan =o)" <danielbass [at] postmaster [dot] co [dot] uk> 写入邮件
> news:ub*************@TK2MSFTNGP11.phx.gbl...
>> Eric,
>>
>> The System.Data.SqlClient library is a pure .Net client interface to the >> database. Therefore if the connection is not closed, there is the timeout >> and garbage collector to sort it out if someone doesn't do the job of
>> closing it down manually.
>>
>> What type of unmanaged resources are you refering too?
>>
>> If the managed code is hooked into native code via the Interop's, then
>> the
>> garbage collector will again call the destructors on your unmanaged code >> when it thinks you're finished with them during a clear up.
>>
>> Therefore if the unmanaged code is not desroying its objects, the garbage >> collector destroy these uncleared objects either as the onus lies with
>> the
>> unmanaged resource and not the .Net application.
>>
>>
>> "Eric" <wa**********@msn.com> wrote in message
>> news:%2****************@TK2MSFTNGP12.phx.gbl...
>> > for example: SqlConnection is used in my project, how can I know if all >> > connections were closed after open and execution. If some guys
>> > forget
>> > to
>> > close connections after using, how can i check it out ?
>> >
>> >
>> > best,
>> > eric
>> >
>> >
>> >
>>
>>
>
>



Nov 16 '05 #6
Dan,

Your comments is helpful, but I have some diffrent viewpoints.

A simply match on Open/Close won't be enough for Resource Safe in dotNET, as
that a simply match on new/delete is not enough for Memory Safe in C++.

To my opinion, Resource Safe is also very important for a business system.
Without Resource Safe, you are unable to say when the system will break
down. Yes, GC maybe help in some situation, but the system may have broken
down before GC.Collect().

So, we have to exactly manually open and free every system resource,
obviating the disturbance of Exceptions. I feel it's even more boring than
keep Memory Safe in C++.

Sorry for the rant.

best,
eric

"Dan =o)" <danielbass [at] postmaster [dot] co [dot] uk> 写入邮件
news:eA**************@tk2msftngp13.phx.gbl...
Eric,

Like I said, it's not right if you don't call close, I don't really see what other option you have on a large scale project. If you have the source, then a simply match on Open/Close calls will do.

"Eric" <wa**********@msn.com> wrote in message
news:%2****************@TK2MSFTNGP11.phx.gbl...
Let's have a test to find out what would happen, if we don't manually call Dispose() or such like that :
using System;
using System.Data;
using System.Data.SqlClient;
using System.Windows.Forms;

namespace PureTest
{
public class Class1
{
public Class1()
{
}

[STAThread]
static void Main()
{
while(true)
{
int i = 0;
try
{
for(i = 0; i < 1000; i++)
{
SqlConnection con = new
SqlConnection("server=ERIC;uid=eric;pwd=eric;datab ase=settlement");
con.Open();
}
}
catch(Exception ee)
{
MessageBox.Show("count=" + i.ToString() + "\r\n");

if(MessageBox.Show(ee.Message + "\r\n\r\ncontinue?", "connect fail",
MessageBoxButtons.YesNo) == DialogResult.No)
{
break;
}

}
}
}
}
}
We will see that connection_pool keep exhausted. This sample looks stupid, but similar situation can really happen in a complex project.

Not_using connection pool, I don't think this is a good idea. Connecting
is
an expensive operation, and Real_Connection to SQLServer is also limited.
best,
eric


"Dan =o)" <danielbass [at] postmaster [dot] co [dot] uk> 写入邮件
news:OB**************@TK2MSFTNGP12.phx.gbl...
Firstly, I'm not sure why this is a problem... The pooling technique is
offered as a default so that the overhead is kept down when two

connections
"appear" to be the same in the same process. This saves memory and

resources
in general. If the connection times out because the "Connection Lifttime" has expired, the the GC removes the pool from memory...

It's not a case of should, you "must" call Close()/Dispose()... Although it's not as imperative as, calling "Open()" say, the fact is, failing to call close leaves this connection wide open, and if you've numerous
different open connections, this in itself saps system resources.

Surely a simply find in the solution on "Open()" will give you an

immediate
listing of all the instances where a connection is established?

Finally, you can turn pooling off by passing in "Pooling=false" in the
connection string. This would mean every new connection that is created
is
set up as a seperate connection, regardless if one (or hundred) just like
it
have already been used.

http://msdn.microsoft.com/library/de...taprovider.asp
If you employ proper connection maintenance from the start, it won't be a problem...
"Eric" <wa**********@msn.com> wrote in message
news:uZ**************@TK2MSFTNGP09.phx.gbl...
> Thank you for your reply.
>
> SqlClient.SqlConnection should manually call Close() or Dispose() after > using. MSDN point out this. If we didn't call Close() or Dispose()
> manually,
> SqlConnecont won't be closed when the connection object is out of
> range,
> GC
> would close the connection object in some magic time. That means, if we > don't call Close() or Dispose() as soon as possible, the
> connection_pool
> would be exhausted.
>
> What's the worse, the connection_pool is organized by *process* and
> *ConnectionString*. This means diffrent modules in one program, would
> share
> a same connection_pool. If one connection_pool was exhausted, we can
> not
> even find out which module cause this problem. In a huge project, this > will
> be a very troublesome problem, I think.
>
>
>
>
> "Dan =o)" <danielbass [at] postmaster [dot] co [dot] uk> 写入邮件
> news:ub*************@TK2MSFTNGP11.phx.gbl...
>> Eric,
>>
>> The System.Data.SqlClient library is a pure .Net client interface to

the
>> database. Therefore if the connection is not closed, there is the

timeout
>> and garbage collector to sort it out if someone doesn't do the job of >> closing it down manually.
>>
>> What type of unmanaged resources are you refering too?
>>
>> If the managed code is hooked into native code via the Interop's, then >> the
>> garbage collector will again call the destructors on your unmanaged

code
>> when it thinks you're finished with them during a clear up.
>>
>> Therefore if the unmanaged code is not desroying its objects, the

garbage
>> collector destroy these uncleared objects either as the onus lies with >> the
>> unmanaged resource and not the .Net application.
>>
>>
>> "Eric" <wa**********@msn.com> wrote in message
>> news:%2****************@TK2MSFTNGP12.phx.gbl...
>> > for example: SqlConnection is used in my project, how can I know

if all
>> > connections were closed after open and execution. If some guys
>> > forget
>> > to
>> > close connections after using, how can i check it out ?
>> >
>> >
>> > best,
>> > eric
>> >
>> >
>> >
>>
>>
>
>



Nov 16 '05 #7

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

3 posts views Thread by Mart Rogers | last post: by
5 posts views Thread by Barry Anderberg | last post: by
4 posts views Thread by Rachel Suddeth | last post: by
6 posts views Thread by William F. Kinsley | last post: by
4 posts views Thread by PromisedOyster | last post: by
1 post views Thread by George2 | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.