使用连接池,正确的方法是什么?

发布于 2024-09-09 10:21:11 字数 425 浏览 6 评论 0原文

今天看到了这个问题,但我不确定我是否理解得很好。同样使用相同的连接字符串会导致它们“共享”连接(如果空闲),对吗?那么,是否可以拥有这样的类,将其作为引用传递给多线程应用程序中的每个客户端,然后调用其方法。无论如何,如果第一个连接成功,不会有短暂的延迟吗?

 public int(string commandText)
    {
      SqlConnection con=new SqlConnection(SOME CONSTRING with pooling ON)
    ...

    }

    public string(string commandText)
    {
      SqlConnection con=new SqlConnection(the same CONSTRING with pooling ON)
    ...
    }

seen question about that today but I not sure whether I understand it well. Also using the same connection string causes that they will "share" connections (if free), right? So is it OK to have class like that, pass it as a reference to each client in multithread app and just call its methods. Anyway, would not there be a short lag in the case the first one gets connected?

 public int(string commandText)
    {
      SqlConnection con=new SqlConnection(SOME CONSTRING with pooling ON)
    ...

    }

    public string(string commandText)
    {
      SqlConnection con=new SqlConnection(the same CONSTRING with pooling ON)
    ...
    }

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

断肠人 2024-09-16 10:21:11

当您不再需要连接时,应始终将其丢弃。处置它们不会关闭连接池中的底层连接,而是将其释放回池中。否则,连接将保持不可用,直到垃圾收集器清理孤立的 SqlConnection 对象。

为了最大限度地利用连接池,您应该始终将连接包含在 using 语句中:

using (SqlConnection con = new SqlConnection(someConnectionString)
{
...
}

由于底层连接保持打开状态,因此频繁处理 SqlConnection 对象不会造成任何损失。下次创建 SqlConnection 时,它将选择池中可用的连接之一。

在多线程应用程序中传递连接是一个坏主意,因为多个线程会尝试同时使用它,从而产生不可预测的结果。一方面,SqlConnection 实例方法不是线程安全的。更糟糕的是,事务是特定于连接的,最终可能会导致一个线程扰乱另一个线程的事务。在每个线程中打开新连接更加容易和安全。

就开销而言,打开新连接时总会有开销,即使使用连接池也是如此。当存在未使用的打开连接可用时,池可以节省您创建新连接的开销。如果您确保尽快释放连接,则不必创建太多连接。

一旦开始使用连接池,您可能会惊讶于您的应用程序真正需要的连接数量如此之少。

You should always dispose of connections when you no longer need them. Disposing them doesn't close the underlying connection in the connection pool, rather it releases it back to the pool. Otherwise the connection will remain unavailable until the Garbage Collector gets around to clean the orphaned SqlConnection objects.

In order to utilize the connection pool to the max you should always include your connections in a using statement:

using (SqlConnection con = new SqlConnection(someConnectionString)
{
...
}

There is no penalty from frequently disposing the SqlConnection objects as the underlying connection remains open. Next time you create a SqlConnection it will pick one of the connections available in the pool.

Passing the connection around in a multithreaded app is a bad idea, as multiple threads will try to use it at the same time with unpredictable results. For one thing, SqlConnection instance methods are NOT thread-safe. Worse, transactions are specific to connections and you can end up with one thread messing another's transaction. Opening a new connection in each thread is much easier and safe.

As far as the overhead is concerned, you will always have an overhead when opening a new connection, even with a connection pool. A pool saves you the overhead of creating a new connection when there an unused open connection is already available. If you make sure you release your connections as soon as possible, you will not have to create too many connections.

You may be surprised how few connections your application really needs once you start using a connection pool.

梦行七里 2024-09-16 10:21:11

SQL 客户端,是否; ODBC、JDBC、ADO.Net 等将根据用于启动连接的连接字符串来控制池。连接字符串有许多参数控制如何管理这些连接,包括池化。尽管特定于 .Net,但此处讨论的概念适用于跨数据库和编程语言: SQL Server .NET Framework 数据提供程序的连接池

The SQL client, whether; ODBC, JDBC, ADO.Net etc. will control the pooling based on the connection string used to initiate a connection. The connection strings have a number of parameters that control how those connections are managed including pooling. Although .Net specific the concepts discussed here apply across databases and programming languages: Connection Pooling for the .NET Framework Data Provider for SQL Server

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文