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