为什么在独立应用程序中需要连接池?

huangapple go评论28阅读模式
英文:

Why do we need a connection pool for a standalone application?

问题

我需要知道为什么独立应用程序需要连接池。根据我的了解,独立应用程序只需要一个数据库连接实例。这就是为什么在使用JDBC创建连接对象时,我们使用单例模式的原因。那么对于独立应用程序来说,使用连接池有什么用呢?如果我使用连接池,是否需要指定最大大小为1?在这里,我尝试使用CP30连接池与本机Hibernate。

英文:

I need to know why we need a connection pool for a standalone application. According to my knowledge, a standalone application needs only one database connection instance. That's why we use the singleton pattern while creating the connection object using JDBC. So what's the use of having a connection pool for a standalone application? If I am using a connection pool, do I need to specify the max size as 1? Here I am trying to use the CP30 connection pool with native Hibernate.

答案1

得分: 1

我同意你有一个独立的应用程序,但这并不意味着你总是需要使用单例设计模式。如果一个单一的应用程序启动多个线程,每个线程连接到数据库,那么单例模式将毫无帮助,你应该实现连接池来优雅地处理数据库操作。

连接池和应用程序(独立或分布式)在某种程度上是相关的,但它主要取决于使用情况。假设你正在开发一个独立的桌面应用程序,它是一个简单的CRUD应用程序,在这种情况下,我同意你不需要实现连接池,但是如果我们讨论的是多用户,而且还是并行的情况,我认为我们应该始终利用连接池。

不确定你的用例是什么,但概括地说,“独立应用程序不需要连接池”的说法并不总是成立。

英文:

I agree you have a stand-alone application, but that does not mean, you always need to use a Singleton design pattern. How about a single application spinning up multiple threads and each thread connecting to the database. In that case, Singleton won't be of any help, and you should implement connection pool, you are gracefully handling the db operations.

Connection pool and applications (stand-alone or distributed), are related to some extent, but it majorly depends on the use case. Suppose you are working on a stand-alone desktop based application, which is a simple CRUD one, in that case, I agree you need not implement connection pool, but in case we are talking about multiple user, and that too parallel, I think we should always leverage connection pool.

Not sure what your use-case talks about, but generalizing the statement, "Stand-alone application, does not need connection pooling", does not stand true always.

答案2

得分: 1

A major reason for using a connection pool is that it makes it easier for your application to recover in case the connection goes bad. The only time I would not use a connection pool was if it was acceptable for the program to fail if the connection stopped working. An example could be a very simple batch job that executed one transaction and the job framework running it would retry it if it failed.

英文:

A major reason for using a connection pool is that it makes it easier for your application to recover in case the connection goes bad. The only time I would not use a connection pool was if it was acceptable for the program to fail if the connection stopped working. An example could be a very simple batch job that executed one transaction and the job framework running it would retry it if it failed.

答案3

得分: 0

连接池的使用成本通常是微不足道的。

您的数据访问层不需要知道它是从独立应用程序调用还是从多线程Web应用程序调用。因此,始终使用连接池是一个很好的理由,它在第一种情况下没有问题,在第二种情况下可能是必需的。

英文:

The cost of using a connection pool is usually insignificant.

Your data access layer does not need to know whether it's being called from a standalone application or, say, a multithreaded web application. So there's a good case for always using connection pooling, which doesn't hurt in the first case and is probably necessary in the second.

huangapple
  • 本文由 发表于 2020年7月31日 16:01:03
  • 转载请务必保留本文链接:https://go.coder-hub.com/63188009.html
匿名

发表评论

匿名网友

:?: :razz: :sad: :evil: :!: :smile: :oops: :grin: :eek: :shock: :???: :cool: :lol: :mad: :twisted: :roll: :wink: :idea: :arrow: :neutral: :cry: :mrgreen:

确定