为什么在客户端请求之间打开数据库连接是个坏主意?

时间:2010-03-16 21:04:29

标签: asp.net design-patterns ado.net

1)我正在阅读的书中认为,不应在客户端请求之间打开连接,因为它们是有限的资源。

我意识到可以快速达到最大池大小,因此任何进一步尝试打开连接都将排队,直到连接可用为止,因此我们必须尽快释放连接。

但假设所有请求都将打开与同一个数据库的连接,那么我不确定如何在两个客户端请求之间打开连接的效率低于让每个请求首先从连接池获取连接并稍后返回对象连接池?

2)Book还建议当数据库代码封装在专用数据访问类中时,打开数据库连接的方法M也应该关闭该连接。

a)我假设M也应该关闭它的一个原因,是因为如果方法M打开连接也不关闭它,但是这个连接对象在几个方法中使用,那么程序员更可能会忘记关闭它。

b)打开连接的方法是否也应该关闭它还有其他原因吗?

感谢名单


编辑:

如果在处理Web请求期间没有关闭连接,则下一个请求不能“直接”使用相同的连接,而是首先需要将其返回到连接池,然后才会可以重复使用吗?如果是这种情况,我可以通过在请求期间保持连接打开来看到我们如何获得任何收益?!

  

E.g。事务1从表中读取一行,然后用户在修改数据之前考虑很长时间。在此期间,事务B读取然后更新同一行:事务A现在具有陈旧数据!现在,如果用户最终修改数据并且tx A提交它,则tx B所做的修改可能会完全丢失:这称为丢失更新。

如果我的上述假设是正确的,那么在第一次请求期间如何启动事务1(因此建立数据库连接1)的用户U获得对相同数据库连接1的引用(因此对事务1的“引用”) )在第二次请求(又称回发)期间?也就是说,当服务器完成处理用户U的第一个请求时,连接对象是否没有返回到连接池?

3 个答案:

答案 0 :(得分:1)

是的,您永远不知道连接将打开多长时间,因为请求是由用户启动的......也就是说,如果请求丢失(用户关闭浏览器)会发生什么,太容易无限地打开连接。如果你这样做,很难有一个清理过程。

HTH。

答案 1 :(得分:1)

2)中的要点可以通过在智能管理器对象中打开和关闭连接来解决。使用数据库的方法会调用此管理器来获取连接并将其返回。经理会计算有多少方法正在使用连接,多久以前等等,并相应地建立/关闭连接。

答案 2 :(得分:1)

是的,在ASP.NET和SQL连接中,极少数场景中不使用连接池是有意义的。连接池导致问题的最常见方案之一是更改上下文(从数据访问/授权角度)。几乎可以把连接池看作是一个连接负载平衡器,它比你要编写代码的任何东西都要高效,直到你学到很多东西,然后写了很多代码。

关于这个主题的几个链接将比我更好地解释它:

first link

second link