我已经编写了一个Windows服务，它监听来自第三方服务的数据，将其在内存中保存一小段时间，并定期将所有新数据刷新到数据库中。
我最初是在每次需要刷新数据时打开一个新的连接，然后再关闭它。（每5秒左右）
由于服务器似乎受到了冲击，我已经改变了这一点，所以只有一个连接打开，并在应用程序的生命周期中重用。
只是想知道这是不是个坏主意？
我通常做的web工作是在一个请求的生命周期内打开和关闭连接。对于需要做我所描述的那种操作的windows服务来说，什么是最好的实践呢？
我打算建立这样的容错连接：
private SqlConnection _sqlConnection;
public SqlConnection SqlConnection
{
get
{
if (_sqlConnection == null || !_sqlConnection.State.Equals(ConnectionState.Open))
{
var conn = new SqlConnection(_connectionString);
conn.Open();
return conn;
}
return _sqlConnection;
}
}因此，如果由于某种原因，现有连接关闭或出现故障，我们将获得一个新的打开连接
这个糟糕设计有什么原因吗？
3条答案
按热度按时间rjee0c151#
如果您是数据库的单个用户，请保持连接。如果不是，您可以真正依靠连接池来为您完成此操作。
我个人倾向于每次都打开连接。在.NET 2.0中实现了一个新功能，如果您有一个到sql服务器的打开连接，并且sql服务器重新启动等...您的连接将变得无效，**这不是我可以拿我的服务冒险的事情。**请参阅几年前的my pos t。
hivapdat2#
说我保守吧，但我仍然认为让连接池来管理到数据库的物理连接是一个更好的选择。因此，只需正常地打开和关闭连接，并让连接池来决定要做什么。我已经在Web服务中这样做了，没有任何问题，您将有更多的连接来处理负载。
pxq42qpu3#
我不会试图维护一个开放的连接。在很多边缘情况下，连接将变得不可用，而管理连接和确保旧的duff连接被正确处理的代码必须是绝对防弹的。
我建议使用更常见的连接使用模式open，use，close/dispose。代码更容易编写和维护。一定要确保在处理完所有命令和连接对象后，将其处理掉。使用分析工具监控应用，并检查服务器上打开的数据库连接的数量，以确保代码按预期方式工作。
需要将数据转储到数据库中（从而打开/使用/关闭数据库连接）的频率取决于许多因素，例如转储前内存中的数据量、数据库服务器使用数据的能力，以及如果已从Web服务接受数据但尚未将其写入数据库而导致服务或服务器崩溃时丢失数据的风险。
如果您的数据很珍贵，您可能需要考虑使用两个进程。一个进程调用Web服务，并将收到的数据安全地存储在消息队列中。另一个进程从队列中读取消息，并将消息中的数据放入数据库。
这种处理此过程的方式意味着您可以在数据库暂时关闭时接收数据，并且所有数据最终都将存储在数据库中。
虽然这是一个坚实的解决方案，它可以很容易地被认为是矫枉过正，这取决于您的要求。