我最近继承了一些代码，我在其中发现了一个在过滤器中初始化的JDBC连接，并为每个用户添加了HttpSession。然后，在用户的Web应用程序的各个部分中重用该连接。这立即让我感觉像代码味道。我想回到编写它的开发人员并解释为什么他不应该这样做......但也许我不太确定自己...
除了在内存中占用不必要的空间并可能限制与数据库的可用连接之外，还有其他原因导致您不在会话中存储JDBC连接吗？
答案 0 :(得分：5)
您已经提到了显而易见的，一个用户到一个数据库连接是不可扩展的。您的用户应与访问数据模型完全分离。以下是您将遇到的几个问题。
答案 1 :(得分：2)
将HttpSession中的JDBC连接保持在堆栈中，甚至访问servlet层上的JDBC连接的整体想法没有多大意义。将连接集中在应用程序服务器上并通过这种方式减少打开连接的数量更有意义。然后，相同的应用程序可以为更多同时用户提供更好的性能。
在大型应用程序中，所有请求都不可能到达数据库，因为无论如何都可能在缓存中找到相同的信息。
在具有非粘性会话的集群环境中，如果请求将打到除创建会话的其他框之外，则JDBC连接甚至无效。
通常，您应该只在会话中存储用户特定信息，甚至将会话所需的数量减少到最小。会话中的更多数据意味着在复制会话时在群集中的应用程序服务器之间传输更多数据（如果会话未存储在中央数据库或缓存中）。
答案 2 :(得分：1)
虽然我无从得知，但我猜想你的同事开始时每个请求从管理器中获取自己的新连接，就像在初学者和演示程序中完成的那样。他很快就发现这种请求放缓了;所以现在他通过在用户会话中“汇集”来避免连接创建。
这解决了在连接上发出第二次和后续请求的用户的性能问题，但这是一个非常笨拙且不可扩展的解决方案。如果您的应用程序的用户群增长，那么打开会话的用户数量将快速超过您的数据库可以为您提供的最大连接数。然后会话或数据库连接出现问题......
“行业标准”解决方案是使用连接池。现代版本的Tomcat具有“内置”连接池，其他Web应用程序服务器也是如此。如果没有，您可以轻松安装自己的。这使您可以完全独立于用户会话管理连接池。
连接池的另一个好处是，一旦池“预热”，即正在使用和初始化多个连接，即使“每个用户会话的第一个请求”也会快速接收连接。因此，总体吞吐量将比目前的情况有所改善。
答案 3 :(得分：1)
为什么不在会话中存储JDBC连接：
连接池可以帮助解决问题1-3。