连接池与每线程 JDBC 连接

发布于 2024-09-02 16:23:16 字数 32 浏览 10 评论 0原文

以下哪种方法更好:连接池或每线程 JDBC 连接?

Which of these approaches is better: connection pooling or per-thread JDBC connections?

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

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

发布评论

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

评论(3

酒绊 2024-09-09 16:23:16

连接池是肯定的,而且几乎总是如此。

创建新的数据库连接对于性能来说代价非常大。不同的数据库引擎(取决于许可或仅取决于设置)具有不同的最大连接数(有时甚至是 1,通常不超过 50)。

使用每线程连接的唯一原因是您知道存在一定数量的少量持久线程(例如 10 个)。我无法想象现实世界中的这种情况。

Connection Pooling for sure and almost always.

Creating new database connection is very costly for performance. And different DB engines (depending on licensing or just settings) has different maximum number of connections (sometimes it even 1, usually not more then 50).

The only reason to use Per-Thread connections is if you know that there are certain small number of persistent threads (10 for example). I can't imagine this situation in real world.

Smile简单爱 2024-09-09 16:23:16

绝对是连接池。绝对没有理由为每个线程创建一个新连接。但是,例如,对整个 HTTP 请求使用相同的连接可能是有意义的(特别是如果您需要事务)。

您可以轻松配置连接池框架,以根据您使用的数据库设置最小和最大连接数。但在将最大连接数设置得太高之前,如果遇到性能问题,请尝试使用缓存。

Definitely connection pooling. Absolutely no reason to create a new connection for each thread. But, it might make sense to use the same connection for an entire HTTP request for example (especially if you need transactions).

You can easily configure the connection pooling framework to have a min and max number of connections depending on the database that you are using. But before going too high with the max number of connections, try using caching if you have performance issues.

云醉月微眠 2024-09-09 16:23:16

对于网络应用程序来说,出于其他人已经提供的原因,连接池通常是正确的答案。

对于大多数针对数据库运行的桌面应用程序来说,连接池并不好,因为您只需要一个连接,而拥有多个连接会消耗数据库服务器上的资源。 (乘以用户数量。)这里的选择是在单个持久连接或仅按需创建连接之间。第一个会导致更快的查询,因为您没有建立和断开连接的开销。第二种速度较慢,但​​对数据库服务器的要求也较低。

For web apps, connection pooling is generally the right answer for reasons other have already offered.

For most desktop apps running against a database, a connection pool is no good since you need only one connection and having multiple connections consumes resources on the DB server. (Multiply that by the number of users.) Here the choice is between a single persistent connection or else just create the connection on demand. The first leads to faster queries since you don't have the overhead of building up and tearing down the connection. The second is slower but also less demanding on the DB server.

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