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