Windows 服务中的 Sql 连接答案

【问题标题】：Sql connection in a windows serviceWindows 服务中的 Sql 连接
【发布时间】：2011-03-29 10:32:11
【问题描述】：

我编写了一个 Windows 服务，它侦听来自第三方服务的数据，将其保存在内存中一小段时间，并定期将所有新数据刷新到数据库中。

每次我需要刷新数据并在之后再次关闭它时，我都会打开一个新连接。（每 5 秒左右）

由于服务器似乎受到重创，我已对其进行了更改，因此在应用程序的生命周期中打开并重用了一个连接。

只是想知道这是不是一个坏主意？

我通常会在单个请求的生命周期内打开和关闭连接的网络工作。对于需要执行我所描述的操作的 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;
    }
}

因此，如果由于某种原因现有连接以某种方式关闭或出现故障，我们将获得一个新的打开的连接

这种糟糕的设计有什么原因吗？

【问题讨论】：

标签： c# .net windows-services connection connection-pooling

【解决方案1】：

使用常识。如果您是数据库的单个用户，请保持连接。如果没有，您真的可以依靠连接池来为您做到这一点。

我个人每次都会去打开连接。在 .NET 2.0 中实现了一项新功能，因此如果您与 sql server 建立了开放连接并且 sql server 重新启动，等等...您的连接将变得无效并且 这不是我可以冒险使用我的服务的事情。 参见几年前的my post。

【讨论】：

【解决方案2】：

称我为保守，但我仍然认为将其留给连接池来管理与数据库的物理连接是更好的选择。所以只要正常打开和关闭连接，然后交给池来决定做什么。我已经在 Web 服务中做到了这一点，没有任何问题，并且您将有更多的可用连接来处理负载。

【讨论】：

【解决方案3】：

我不会尝试保持打开的连接。将会有很多边缘情况，连接将变得不可用，并且您用于管理连接并确保正确处理旧的 duff 连接的代码必须绝对防弹。

我推荐更常见的连接使用模式 open、use、close/dispose。代码将更容易编写和维护。绝对确保在处理完所有命令和连接对象后处理它们。使用分析工具监控您的应用，并检查服务器上打开的数据库连接的数量，以确保您的代码按预期方式运行。

您需要多久将数据转储到数据库中（以及因此打开/使用/关闭数据库连接）取决于许多因素，例如转储前内存中的数据量、数据库的能力服务器来使用数据，如果您已从 Web 服务接受数据但尚未将其写入数据库并且您的服务或服务器崩溃，则存在丢失数据的风险。

如果您的数据很宝贵，您可能需要考虑使用两个流程。一个进程调用 Web 服务并将接收到的数据安全地存储在消息队列中。另一个进程从队列中读取消息，并将消息中的数据放入数据库中。

这种处理这个过程的方式意味着您可以在数据库暂时关闭时接收数据，并且所有数据最终都将存储在数据库中。

虽然这是一个可靠的解决方案，但也很容易被认为是矫枉过正，具体取决于您的要求。

【讨论】：