保持数据库连接长时间打开是否安全

Question

我有一个连接到远程数据库的.net客户端应用程序。 在客户的整个生命周期内保持一个连接是否安全（小时）？

如果我有多个（10或100）客户端正在运行，答案是否成立？

由于

Answer 1

这样做绝对是安全的。这是客户端 - 服务器应用程序的工作方式如果您使用的是三层应用程序，则应用程序服务器将保持打开的连接池。

可扩展性是一个问题，或者至少曾经是机器内存少于现代套件的日子。使用双层（客户端 - 服务器）应用程序，每个客户端打开一个连接并保持打开状态。这有几个影响：

• 每个连接使用内存，所以 大量（相对）空闲 连接将耗尽机器 记忆。但是，现代的64位 服务器可以有几十或几百个 GB的内存，所以它可以支持一个 这样的人数非常多 连接。

• 如果还有交易 在客户端计算机上未提交， 锁将保持打开状态 交易是开放的。 这导致了一类问题 有人可以开始交易， 去吃午饭，忘了他们有 留下一些东西。这个会 锁定由引用的任何记录 一次几小时的交易。

• 交易可以很容易 覆盖多个加入 数据库，这很难做到 连接池。

在3层体系结构中常见的池化体系结构在应用程序服务器和数据库之间具有有限数量的连接。查询只使用下一个可用连接，并立即提交更新。这使用较少的资源，因为您只打开了有限数量的连接，并且（与optimistic concurrency策略结合使用）将消除大量潜在的应用程序并发问题。

为了使用long transactions（即覆盖多个数据库调用的事务），必须将事务与连接分离。这是TP监视器的基本架构，有一些标准协议，如XA或OLE Transactions来支持这一点。如果此类外部管理事务不可用，则应用程序必须构造一个compensating transaction来撤消应用程序事务所做的更改。这种类型的体系结构通常由workflow management systems.

使用

Answer 2

按业务操作打开和关闭您的连接

如果您正在谈论客户端/服务器应用程序，我建议您在完成使用后立即关闭每个连接。虽然每个单独的应用程序实例可能会打开连接的小性能命中，但整个应用程序的扩展性会更好。这在某种程度上取决于您使用的数据库服务器。 SQL Server将根据安装的硬件处理不同数量的并发连接。如果您想将客户端/服务器应用程序扩展到数千个桌面，小型数据库服务器可能无法处理所有具有开放连接的桌面，但可以很好地处理数千个桌面，只打开一些连接。

几年前我亲眼看到了这一手。然后，在整个组织中部署了一个部署到几个没有问题的部门的应用程序。申请很快就非常非常缓慢。该组织正在考虑为他们的数据库服务器购买一块非常昂贵的硬件以获得一些性能。我建议他们在每次业务操作后打开和关闭数据库连接。幸运的是，他们已经构建了应用程序，因此这不是一个很难的改变。他们在每周一次的网络更新中进行了更改并将其推出。一夜之间，应用程序性能得到了显着改善。他们节省了数千美元。

Answer 3

长期关系的困难在于你可能不完全确定它们仍然在那里。网络故障，服务器重启或状态防火墙忘记某些状态都可能导致“陈旧”连接看起来开放，但是当您尝试使用它时会出错。

连接池方案通常通过让某个系统偶尔检查池中的连接是否正常，或者在删除未使用的连接之后超时来解决此问题。

一般来说，在分布式系统中，您需要围绕各种类型的故障进行编码，保持长期连接打开会使这更加困难 - 但如果您乐意这样做，那就太好了。

Answer 4

虽然具体细节一般很重要，但保持连接长时间打开并没有错。

如果您的应用程序是连接池，则池中的连接插槽通常会保持连接状态，直到需要它们为止。

在基于连接的许可证模型之外，现在极其罕见的维护连接本身消耗的资源可以忽略不计。

通过TCP操作的SQLServer客户端以30秒的间隔发送keepalive。 （Keepalive本质上是0 len TCP数据包） ususally 是可以忽略不计的流量。

如果您在带宽很小或WLAN链路不可靠的环境中运行，那么增加TCP保持活动间隔可能有助于提高长时间连接保持活动状态的可能性，并减少线路上“空闲聊天”的数量。

您可能会或不想使用连接池。

反对使用游泳池：

消除环境污染的可能性 - 其他查询设置可能干扰查询执行的特殊环境选项（xact_abort，事务隔离级别等等）

如果配置/许可的连接限制有效，则应用程序中的空闲连接是不可供其他应用程序使用的连接。

每次反对连接：

连接设置（尤其是安全连接设置）需要在客户端和服务器之间进行多次额外的往返 - 往返往往是WAN应用程序的性能杀手。

Answer 5

一般来说，你不应该像这样保持联系。 .NET有一个ADO.NET连接池系统，它可以完成你想要做的事情，并且做得更好。 ; - ）

更新：我是个小孩。反应性地发布。不适用于此。

-Oisin

Answer 6

不确定。当您长时间持有交易（在某些隔离级别）时，您确实只会遇到问题。

存在许可连接限制，并且连接确实占用服务器上的内存，因此越少越好。

Answer 7

很安全。这几乎就是池的作用......在程序运行的长度内保持连接打开并将其用于不同的查询。

但您可能需要注意数据库连接超时。连接将变得陈旧，你将开始得到奇怪的错误。将数据库中的超时值设置为非常大的值，或者使用偶尔的虚拟查询保持连接。

Answer 8

它确实取决于您使用开放连接的客户端数量以及您是否使用任何类型的连接池。

如果您是三层系统且中间层启用了连接池，则客户端设置不适用。如果您不使用中间层，现在是时候考虑它，如果您担心与服务器的连接数量，因为这个中间层将帮助您更好地管理它。

每个打开的连接都会在服务器上占用一定量的内存，并增加一些开销。给定一个双层系统，客户端直接与服务器通信，然后您需要查看服务器的规格和客户端数量，以查看是否打开连接是值得的。如果你是一个双层系统，并且你有成千上万的活跃客户端，那么你可能不想让它们全部开放...如果你是一个双层系统而且只有几十个客户端，那么让它们保持打开状态

Answer 9

取决于数据库以及您正在使用它做什么。在大多数情况下打开和关闭任何连接都需要付费。例如，如果您在移动设备（SQL Server Compact Edition）上使用SQLCE，那么实际上建议的方法是在设备上打开连接，因为打开和关闭它的费用不值得麻烦。

现在相反，如果您正在使用多用户数据库，那么您将需要更仔细地管理这些连接。如前所述，ADO.Net连接池在帮助您管理效率方面做得非常好。