共享DB连接与私有DB连接

Question

试图找出如何管理/使用长期存在的DB连接。我对这种类型的体验太少了，因为我只在小型系统中使用过DB (多达150个并发用户，每个并发用户都有自己的DB用户/pass，因此在任何时候都有多达150个长期存在的DB连接)或网页(每个页面请求都有自己的数据库连接，持续时间不到一秒钟，因此并发DB连接的数量并不多)。

这一次将有一个Java服务器和Flash客户端。Java连接到PostgreSQL。连接预计会持续很长时间，也就是说，当Flash客户端连接到Java服务器时，它们就会启动；当Flash客户端断开连接时，连接就会结束。最好是在所有用户(客户端)之间共享单个连接，还是为每个客户端建立私有连接？或者其他的解决方案会更好？

*单一/共享连接：

对于整个system，

• (+)
  • 只有一个DB连接

​

• transactions (-)缺点:不能使用
  • (-) (例如，"user1.startTransaction()；user1.updateBooks()；user2.updateBooks()；user1.rollback();“对单个共享连接进行回滚更改(由user2执行)
  • 对一个用户的长时间查询可能会影响其他用户(不确定这一点，though)

)

​

*私人联系：

事务:)没有问题的

• (+)

​

• (-)缺点：
  • 可能需要大量并发连接，也就是说，如果在线用户为10000，则需要10000 DB连接，这似乎太高了:)不过，我对预期用户数一无所知，因为我们还在进行研究和使用

​

一种解决方案是引入超时，即如果DB连接在15/60/900(?)几秒钟后，它就断了。当用户再次需要DB时，它会重新连接。对我来说，这似乎是一个很好的解决方案，但我想知道这方面的合理限制可能是什么，例如，并发DB连接的最大数量可能是多少，应该使用什么超时等等。

另一种解决方案是将查询分为两种“类型”--一种类型可以安全地使用单个共享长生命连接(例如，"update last_visit = now() where id = :user_id")，另一种类型需要私有短生命连接(例如，一些可能会做一些繁重工作或使用事务的东西)。这个解决方案似乎对我没有吸引力，但如果应该这样做，我可以尝试这样做.

所以..。在这种情况下，其他开发人员会做什么呢？还有其他合理的解决办法吗？

Answer 1

我不使用长久的关系。我使用一个连接池来管理连接，并且只在执行操作所需的时间内保留它们:获取连接，执行我的SQL操作，将连接返回到池。它的可伸缩性要高得多，并且不受事务问题的影响。

让容器为您管理池-这就是它的目的。

Answer 2

通过使用单个连接，您还可以获得非常低的性能，因为数据库服务器将只为您分配一个连接。

你肯定需要一个连接池。如果应用程序在应用程序服务器中运行，请使用容器池。或者您可以使用连接池库(如c3p0 )。