druid数据库连接池用不用关闭

druid数据库连接池用不用关闭,第1张

使用完后必须con.close()掉,

使用连接池的话,执行con.close并不会关闭与数据库的TCP连接,而是将连接还回到池中去,如果不close掉的话,这个连接将会一直被占用,直接连接池中的连接耗尽为止。

首先要说明的是连接数是有限制的:

代码如下:

for (int i = 0i <10000i++)

{

SqlConnection conn = new SqlConnection(@"Data Source=.\SQLEXPRESS

AttachDbFilename=""E:\DB\NORTHWND.mdf""

Integrated Security=TrueConnect Timeout=30User Instance=True")

conn.Open()

Console.WriteLine("打开了{0}个连接", i)

}

运行结果如下:

过一会就会提示打开连接超时了:

可以看到数据库连接时有限制的,如果连接不关闭,而且使用的人比较多,那么系统很快就down掉了。

但是有时候由于某些原因应用程序可能只是几个人使用,所以就有人设计了:

在应用程序启动的时候打开数据库连接,在应用程序关闭的时候关闭数据库连接

那么使用这种方式有什么问题呢?

首先假设有一张表Nums,表定义如下:

Main代码如下:

SqlConnection conn = new SqlConnection(@"Data Source=.\SQLEXPRESS

AttachDbFilename=""E:\DB\NORTHWND.mdf""

Integrated Security=TrueConnect Timeout=30User Instance=True")

conn.Open()

Parallel.For(1, 9999, (id) =>

{

ExecuteCommand(conn, id)

})

就是从1到9999开始执行ExecuteCommand

ExecuteCommand代码如下:

private static void ExecuteCommand(SqlConnection conn, int id)

{

Console.WriteLine("正在执行." + id)

Thread.Sleep(100)

SqlCommand cmd = new SqlCommand(

string.Format("Insert into Nums values('{0}') ", id), conn)

cmd.ExecuteNonQuery()

}

运行:

可以看到ExecuteNonQuery方法抛出了异常,原因是连接处于关闭状态。

可是我们的连接一直都是open着的啊,并没有调用close,dispose之类的方法啊。

于是在ExecuteCommand前面增加判断条件:

if (conn.State != System.Data.ConnectionState.Open)

conn.Open()

再次运行:

可以看到还是会出现连接已关闭的问题。你知道什么原因吗?

这里是由于多线程环境引起的。所以需要加锁。

private static object syncObj = new object()

private static void ExecuteCommand(SqlConnection conn, int id)

{

lock (syncObj)

{

if (conn.State != System.Data.ConnectionState.Open)

conn.Open()

Console.WriteLine("正在执行.." + id)

Thread.Sleep(100)

SqlCommand cmd = new SqlCommand(

string.Format("Insert into Nums values('{0}') ", id), conn)

cmd.ExecuteNonQuery()

}

}

再次运行:可以发现基本没问题了.

修改Parallel.For的最大值上限,要测试下是否可以长期执行了。

Parallel.For(1, Int32.MaxValue, (id) =>

{

ExecuteCommand(conn, id)

})

一天测试下来,没出现任何问题。

结论:对于某些只有几个人使用的应用程序,可以不关闭数据库连接,但是在写代码的时候最好要加上连接是否打开的判断。

你有什么好的看法呢,欢迎留下!

作者:LoveJenny

出处:http://www.cnblogs.com/LoveJenny/

本文版权归作者和博客园共有,欢迎转载,但未经作者同意必须保留此段声明,且在文章页面明显位置给出原文连接,否则保留追究法律责任的权利。

分类: C#

正确使用SqlConnection对象,兼谈数据库连接池

今晚看到上了评论头条的LoveJenny写的为什么要关闭数据库连接,可以不关闭吗?,文章写得简单易懂非常不错,而且代码贴的很到位,下面的讨论也很激烈(老赵都跑过去留言两次了,我恨)。又查看了两遍原文中的代码,我同意评论中有几位的看法,真正造成多线程并行 *** 作数据库时的连接问题可能是由于对SqlConnection的不当使用。为什么呢?再来看一下LoveJenny兄弟贴出的一段重要源码:

1

2

3

4

5

6

7

8

9

string sqlConnString

= @"Data

Source=.\SQLEXPRESS

AttachDbFilename=""E:\DB\NORTHWND.mdf""

Integrated

Security=TrueConnect Timeout=30User Instance=True"

SqlConnection

conn = new SqlConnection(sqlConnString)

conn.Open()

Parallel.For(1,

Int32.MaxValue, (id) =>

{

ExecuteCommand(conn,

id)

})

其中,ExecuteCommand的具体实现如下:

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

private static object syncObj

= new object()

private static void ExecuteCommand(SqlConnection

conn, int id)

{

lock (syncObj)

{

if (conn.State

!= ConnectionState.Open)

{

conn.Open()

}

Console.WriteLine("正在执行." +

id)

Thread.Sleep(100)

SqlCommand

cmd = new SqlCommand(

string.Format("Insert

into Nums values('{0}') ",

id), conn)

cmd.ExecuteNonQuery()

}

}

代码很简洁,但是很多人包括我自己忍不住都会有几个重大疑问:

1、怎么并行 *** 作n多次数据库只共用一个连接对象呢?

2、并行处理的地方加了锁,每次进行数据库 *** 作都要Lock一下(我感觉这根本没有发挥多线程并行处理的优势,个人认为还不如单线程执行的快呢),这个真的有这个必要吗?

3、同一个数据库连接字符串,使用数据库连接对象SqlConnection怎么还要传参呢,显式Open和Close不是更好吗?通常不都是using一下完事吗?

经过简单思考之后,在本地机器上改进了一下实现代码进行测试,如下:

1

2

3

4

Parallel.For(1,

Int32.MaxValue, (id) =>

{

ExecuteCommand(id)

})

ExecuteCommand方法不再接受SqlConnection对象作为参数,去掉Lock,数据库 *** 作看上去就像是 *** 作一次数据库,打开一次数据库连接,保证线程安全:

1

2

3

4

5

6

7

8

9

10

11

12

private static void ExecuteCommand(int id)

{

using (SqlConnection

conn = new SqlConnection(sqlConnString))

{

conn.Open()

Console.WriteLine("正在执行." +

id)

Thread.Sleep(100)

SqlCommand

cmd = new SqlCommand(

string.Format("Insert

into Nums values('{0}') ",

一般情况下使用完都会关的

但是例如连接池这种,就是大家直接使用即可,当web服务器结束时自动由框架帮你关闭。

我感觉关闭不关闭的原则是:如果可以很好的控制连接数量和最后的连接关闭,可以不用每次都关闭。


欢迎分享,转载请注明来源:内存溢出

原文地址: http://outofmemory.cn/sjk/9945912.html

(0)
打赏 微信扫一扫 微信扫一扫 支付宝扫一扫 支付宝扫一扫
上一篇 2023-05-03
下一篇 2023-05-03

发表评论

登录后才能评论

评论列表(0条)

保存