Question

我继承了.NET桌面应用程序，并试图找出一个未释放数据库锁的间歇性错误。

该应用程序采用Singleton方法来建立SQLConnection，我想知道在内存中创建并保持打开SQLConnection的单个实例是否会导致这种情况？

我知道连接池使此代码变得多余。我想知道的是：考虑到我的单线程桌面应用程序的每个实例只有一个用户的情况，这种方法会引起问题吗？

private static SqlConnection connection;

public static SqlConnection Connection
{
    get
    {
        if (connection == null) {
            connection = new SqlConnection();
            connection.ConnectionString = "...";
            connection.Open();
        }
        if (connection.State != ConnectionState.Open) {
            connection.Open();
        }
        return connection;
    }
}

编辑＃1 ：我知道这不是最佳做法；我知道连接应该延迟打开，并尽早关闭；我知道连接池使此代码变得多余。在我的特定情况下，这个问题可以证明吗？

Answer 1

这是一个过时的旧设计，现在不赞成使用，以使连接器保持尽可能少的打开状态，并在每次使用后使用using子句将其关闭并立即处置，

说您上面显示的模式不应仅由于自身原因而创建数据库锁，

考虑到即使连接保持打开状态更长的时间，连接本身也只是一个通道，所以大多数事情取决于您将其与Command和Reader对象一起使用的方式，在可能的情况下，无论如何，您都应该关闭并处置它。需要更长的时间。

如果数据库中锁定了一些表，那是不是因为多个用户试图同时访问相同的对象而发生这种情况？

Answer 2

为SqlConnection对象使用Singleton是一个非常非常糟糕的主意。没有任何理由这样做。

如果您尝试避免对“ new SqlConnection（）”或“ connection.Open（）”的性能造成影响，则建议不要因为在后台进行连接池而确实对性能造成影响。连接池处理昂贵的连接的打开/关闭。不是SqlConnection对象。

您将无法同时使用连接打开多个SqlDataReaders / Commands，并且如果您尝试与多个线程共享同一连接对象，则会遇到线程阻塞问题。

“单例”模式是最经常使用和滥用的模式，您可能没有意识到单例的许多副作用。在http://www.youtube.com/watch?v=-FRm3VPhseI

上非常好的谈论单身人士的危险

在单个用户.NET桌面应用程序中使用Singleton SQLConnection可能会发生问题吗？

2 个答案: