Peter,
The command is AFAIK managed code that has no unmanaged resources.
In my idea are you only spoiling time in by letting calling senseless times
the dispose l. (It would not heart the processor probably for less then
0.0001 procent, however).
Using the using is in this sitation only helping that you are writing from a
personal view maybe a little bit more elegant code (which than includes as
in every for you generic created code some overhead, but that falls than in
that 0.0001 procent).
From the three ways of coding I have seen now in this thread, I found the
way from Danny the nicest, so what is wrong with that?
Cor
"Peter Duniho" <Np*********@nnowslpianmk.comschreef in bericht
news:op***************@petes-computer.local...
On Mon, 21 Apr 2008 20:18:27 -0700, Danny Ni <dn**@yahoo.comwrote:
I inherited a web project from other programmer. I notice on my dev
machine every time I request a page in IE or FF the CPU jumps to 100%,
all
utilized by asp_wp.exe.
I did some researches on the web, somebody suggests this could be due to
database connection not properly disposed. I happened to see the
following
code snippet in my web project:
static public IDataReader GetRS(String Sql)
{
SqlConnection dbconn = new SqlConnection();
dbconn.ConnectionString = DB.GetDBConn();
dbconn.Open();
SqlCommand cmd = new SqlCommand(Sql, dbconn);
return cmd.ExecuteReader(CommandBehavior.CloseConnection) ;
}
I don't see dbconn.Dispose() or cmd.Dispose() getting called. Is this a
problem? If it is, where should I put the cmd.Dispose() and
dbconn.Dispose()?
Well, according to the docs, closing the connection is "functionality
equivalent" to disposing it. So I would expect the CloseConnection value
passed to the ExecuteReader() method to handle that for you. However,
that still leaves the SqlCommand instance undisposed.
If you're concerned that CloseConnection might not be sufficient or that
failure to dispose the SqlCommand is also a potential problem, you could
always call Dispose() on them after calling ExecuteReader() and before
returning:
static public IDataReader GetRS(String Sql)
{
SqlConnection dbconn = new SqlConnection();
IDataReader reader;
dbconn.ConnectionString = DB.GetDBConn();
dbconn.Open();
SqlCommand cmd = new SqlCommand(Sql, dbconn);
reader = cmd.ExecuteReader(CommandBehavior.CloseConnection) ;
cmd.Dispose();
dbconn.Dispose();
return reader;
}
Or perhaps preferable even:
static public IDataReader GetRS(String Sql)
{
using (SqlConnection dbconn = new SqlConnection())
{
dbconn.ConnectionString = DB.GetDBConn();
dbconn.Open();
using (SqlCommand cmd = new SqlCommand(Sql, dbconn))
{
return
cmd.ExecuteReader(CommandBehavior.CloseConnection) ;
}
}
}
If with those changes, you still have the high CPU problem, then obviously
a simple lack of disposal isn't your problem. I suppose you might look
into whether disabling connection pooling affects the behavior (which
connection pooling, a close/dispose doesn't necessarily actually close the
connection). But that doesn't necessarily mean you'd actually want to
disable connection pooling; it's just a way of getting more information
about what's going on.
Is the high CPU usage actually causing a problem? If the process is at a
low enough priority, I would expect it to not be an issue. If it's
intentional, then hopefully the code is careful to run at a lower
priority. If it's a bug, I suppose all bets are off...sorry for not
having any specific knowledge about that particular behavior.
Pete
