抓住datareader后是否需要关闭连接? [英] Do I need to close a connection after grabbing a datareader?

查看:52
本文介绍了抓住datareader后是否需要关闭连接?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

你好,


我在实用程序类中有一个泛型方法,它抓取sqldatareader

并返回它。由于(AFAIK)的事实,你在读取数据之前不能关闭

数据库连接,这种方法不会接近
关闭它,它只返回datareader。调用代码使用

datareader,然后让它退出范围,由垃圾收集器获取。


这是一个问题吗?我的一个朋友告诉我,没有明确说明关闭连接的
将使其保持打开状态,从而导致连接

池被清空。我没有在服务器上看到任何问题,但是

并没有证明什么。我以前假设连接对象被销毁时连接将被关闭。这是对的吗?


有人评论吗? TIA


-

Alan Silver

(此行下方添加的任何内容都与我无关)

Hello,

I have a generic method in a utility class that grabs an sqldatareader
and returns it. Due to the fact that (AFAIK), you can''t close the
database connection before you''ve read the data, this method doesn''t
close it, it just returns the datareader. The calling code uses the
datareader and then just lets it drop out of scope, to be picked up by
the garbage collector.

Is this a problem? A friend of mine suggested to me that not explicitly
closing the connection will leave it open, resulting in the connection
pool being emptied. I''ve not seen any problems on the server, but that
doesn''t prove anything. I previously assumed that the connection would
be closed when the connection object was destroyed. Is this right?

Anyone care to comment? TIA

--
Alan Silver
(anything added below this line is nothing to do with me)

推荐答案

" Alan Silver" <人********* @ nospam.thanx.invalid>在消息中写道

新闻:哟************** @ nospamthankyou.spam ......
"Alan Silver" <al*********@nospam.thanx.invalid> wrote in message
news:yo**************@nospamthankyou.spam...
我以前假设当
连接对象被销毁时,连接将被关闭。这是正确的吗?


不一定......

有人评论吗? TIA
I previously assumed that the connection would be closed when the
connection object was destroyed. Is this right?
Not necessarily...
Anyone care to comment? TIA




你说你的方法将一个DataReader对象返回给它的调用者...因此,

只需执行以下操作,连接就会得到自动关闭。


return(< MyCommandObject> .ExecuteReader(CommandBehavior.C loseConnection));



You say your method returns a DataReader object to its caller...therefore,
just do the following, and the connection gets closed automatically for you.

return (<MyCommandObject>.ExecuteReader(CommandBehavior.C loseConnection));


来电者然后负责关闭数据阅读器。如果

datareader是通过调用

ExecuteReader(CommandBehavior.CloseConnection)创建的,那么关闭数据读取器

将关闭基础连接。如果这不是数据引导器创建的方式,那么关闭数据读取器将不会关闭连接,并且你将会因连接泄漏而结束。

将结束连接泄漏。


你现在这样做的方式会在

加载下导致连接泄露,你的朋友是正确的。


当对象被销毁时连接将被关闭 - 问题是,

你不知道那是什么。超出范围与收集垃圾的

不一样。当GC需要回收一些内存时,GC会运行,而不是在变量超出范围时 - 但你很可能会因为连接中的连接用完了在此之前的游泳池。


" Alan Silver" <人********* @ nospam.thanx.invalid>在消息中写道

新闻:哟************** @ nospamthankyou.spam ...
The caller would then be responsible for closing the data reader. If the
datareader was created by calling
ExecuteReader(CommandBehavior.CloseConnection), then closing the data reader
will close the underlying connection. If this is not how the datareader was
created, then closing the data reader will not close the connection and you
will wind up with a connection leak.

The way you are doing it right now will end up in a connection leak under
load, your friend is correct.

The connection will be closed when the object is destroyed - the problem is,
you don''t know what that will be. Going out of scope is not the same as
being garbage collected. The GC will run when it needs to reclaim some
memory, not as soon as a variable goes out of scope - but you are likely to
run out of connections in the pool far before then.

"Alan Silver" <al*********@nospam.thanx.invalid> wrote in message
news:yo**************@nospamthankyou.spam...
你好,
<我在实用程序类中有一个泛型方法,它抓取sqldatareader并返回它。由于(AFAIK)的事实,你在读取数据之前不能关闭数据库连接,这种方法不会关闭它,它只会返回datareader。调用代码使用datareader然后
让它退出范围,由垃圾收集器拾取。

这是一个问题吗?我的一位朋友告诉我,没有明确地关闭连接将使其保持打开状态,从而导致连接池被清空。我没有在服务器上看到任何问题,但是
并没有证明什么。我以前认为在连接对象被销毁时连接将被关闭。这是对的吗?

任何人都在评论? TIA

-
Alan Silver
(此行下面添加的任何内容都与我无关)
Hello,

I have a generic method in a utility class that grabs an sqldatareader and
returns it. Due to the fact that (AFAIK), you can''t close the database
connection before you''ve read the data, this method doesn''t close it, it
just returns the datareader. The calling code uses the datareader and then
just lets it drop out of scope, to be picked up by the garbage collector.

Is this a problem? A friend of mine suggested to me that not explicitly
closing the connection will leave it open, resulting in the connection
pool being emptied. I''ve not seen any problems on the server, but that
doesn''t prove anything. I previously assumed that the connection would be
closed when the connection object was destroyed. Is this right?

Anyone care to comment? TIA

--
Alan Silver
(anything added below this line is nothing to do with me)



感谢你们两位回复。


所以,我认为如果实用程序方法创建了一个

命令对象(cmdCommand) ),然后执行类似...


SqlDataReader dtrData = cmdCommand.ExecuteReader(CommandBehavior.CloseConn ection);

return dtrData;


然后调用代码只需要...


SqlDataReader myData = utilmethod(...);

/ /用datareader做东西

myData.Close();


....一切都会好的?请检查我是否正确。


再次感谢


文章< eC ********* *****@TK2MSFTNGP09.phx.gbl> ;,Marina Levit

[MVP]" <所以***** @ nospam.com>写
Thanks to both of you for the replies.

So, am I correct in thinking that if the utility method creates a
command object (cmdCommand), and then does something like...

SqlDataReader dtrData = cmdCommand.ExecuteReader(CommandBehavior.CloseConn ection);
return dtrData;

then the calling code just needs to do...

SqlDataReader myData = utilmethod(...);
// do the stuff with the datareader
myData.Close();

....and all will be fine? Please check I''ve got this right.

Thanks again

In article <eC**************@TK2MSFTNGP09.phx.gbl>, "Marina Levit
[MVP]" <so*****@nospam.com> writes
然后调用者将负责关闭数据读取器。如果通过调用
ExecuteReader(CommandBehavior.CloseConnection)创建了
datareader,则关闭数据读取器将关闭基础连接。如果这不是创建datareader的方式,那么关闭数据读取器将不会关闭连接,您将终止连接泄漏。

你的方式现在这样做将最终导致连接泄漏,你的朋友是正确的。

当对象被销毁时连接将被关闭 - 问题是,
你不知道会是什么。超出范围与垃圾收集不同。 GC将在需要回收一些内存时运行,而不是在变量超出范围时立即运行 - 但是在此之前你很可能会在池中耗尽连接。

Alan Silver <人********* @ nospam.thanx.invalid>在消息中写道
新闻:哟************** @ nospamthankyou.spam ...
The caller would then be responsible for closing the data reader. If the
datareader was created by calling
ExecuteReader(CommandBehavior.CloseConnection), then closing the data reader
will close the underlying connection. If this is not how the datareader was
created, then closing the data reader will not close the connection and you
will wind up with a connection leak.

The way you are doing it right now will end up in a connection leak under
load, your friend is correct.

The connection will be closed when the object is destroyed - the problem is,
you don''t know what that will be. Going out of scope is not the same as
being garbage collected. The GC will run when it needs to reclaim some
memory, not as soon as a variable goes out of scope - but you are likely to
run out of connections in the pool far before then.

"Alan Silver" <al*********@nospam.thanx.invalid> wrote in message
news:yo**************@nospamthankyou.spam...
你好,

我在实用程序类中有一个泛型方法,它抓取sqldatareader并返回它。由于(AFAIK)的事实,你在读取数据之前不能关闭数据库连接,这种方法不会关闭它,它只会返回datareader。调用代码使用datareader然后
让它退出范围,由垃圾收集器拾取。

这是一个问题吗?我的一位朋友告诉我,没有明确地关闭连接将使其保持打开状态,从而导致连接池被清空。我没有在服务器上看到任何问题,但是
并没有证明什么。我以前认为在连接对象被销毁时连接将被关闭。这是对的吗?

任何人都在评论? TIA

-
Alan Silver
(此行下面添加的任何内容都与我无关)
Hello,

I have a generic method in a utility class that grabs an sqldatareader and
returns it. Due to the fact that (AFAIK), you can''t close the database
connection before you''ve read the data, this method doesn''t close it, it
just returns the datareader. The calling code uses the datareader and then
just lets it drop out of scope, to be picked up by the garbage collector.

Is this a problem? A friend of mine suggested to me that not explicitly
closing the connection will leave it open, resulting in the connection
pool being emptied. I''ve not seen any problems on the server, but that
doesn''t prove anything. I previously assumed that the connection would be
closed when the connection object was destroyed. Is this right?

Anyone care to comment? TIA

--
Alan Silver
(anything added below this line is nothing to do with me)





-

Alan Silver

(此行下面添加的任何内容都与我无关)



--
Alan Silver
(anything added below this line is nothing to do with me)


这篇关于抓住datareader后是否需要关闭连接?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆