Java 在HttpSession中存储JDBC连接

我最近继承了一些代码，在这些代码中，我发现一个JDBC连接正在过滤器中初始化，并为每个用户添加了HttpSession。然后，在web应用程序的各个部分中为用户重用该连接。这立刻让我觉得这是一种代码气味。我想回到编写它的开发人员那里，解释为什么他不应该这么做。。。但也许我自己不太确定

---

除了占用内存中不必要的空间并可能限制到数据库的可用连接之外，还有其他原因不在会话中存储JDBC连接吗？

您提到了一个明显的问题，即一个用户到一个数据库的连接是不可伸缩的。您的用户应该与对数据模型的访问完全分离。以下是您将遇到的几个问题

• 如果连接变得陈旧，会发生什么情况？如果没有数据库连接，该用户将无法执行任何有用的操作，因此他们可能必须先注销，然后再重新登录以获得新连接。疯了
• JDBC连接不是线程安全的。如果一个用户决定同时运行两个东西，那么所有的麻烦都会爆发

---

保持JDBC连接在堆栈中的地位与在HttpSession中一样高，甚至在servlet层上访问JDBC连接的整个想法没有多大意义。将连接集中在应用服务器上并以这种方式减少打开的连接的数量更有意义。这样，同一个应用程序就能够以更好的性能为更多的同时用户提供服务

在大型应用程序中，不太可能所有请求都会命中数据库，因为缓存中可能会找到相同的信息

在具有非粘性会话的集群环境中，如果请求命中的框不是创建会话的框，则JDBC连接甚至无效

---

通常，您应该在会话中只存储特定于用户的信息，甚至可以将会话中所需的信息量降至最低。会话中的更多数据意味着在复制会话时，集群中的应用程序服务器之间要传输更多的数据（以防会话未存储在中央数据库或缓存中）。

虽然我不知道，但我还是大胆猜测，您的同事一开始的每个请求都会从管理器获取自己的新连接，就像在初学者和演示程序中一样。他很快发现这大大降低了请求的速度；所以现在他通过在用户会话中“共享”连接来避免创建连接

这解决了用户在连接上进行第二次和后续请求时的性能问题，但这是一个非常笨拙且不可扩展的解决方案。如果应用程序的用户群增加，则具有打开会话的用户数将很快超过数据库可以提供给您的最大连接数。然后会出现会话或数据库连接超时的问题

“行业标准”解决方案是使用连接池。与其他Web应用服务器一样，Tomcat的现代版本具有“内置”连接池。如果没有，您可以轻松安装自己的。这允许您完全独立于用户会话管理连接池

---

连接池的另一个好处是，一旦池“预热”，即大量连接正在使用和初始化，即使“每个用户会话的第一个请求”也会快速接收连接。因此，总体吞吐量将比当前情况有所提高。

为什么不在会话中存储JDBC连接：

• 会话和连接超时可能会导致问题
• 无法独立扩展连接与会话
• 线程安全
• 会话复制将无法工作-引入不必要的状态
• 没有良好的附着力/内聚性设计-糟糕的体系结构无法将不同的关注点解耦

---

连接池可以帮助解决问题1到3。

也许你应该向我们解释为什么你认为他不应该先这么做？@Thorbjørn我想我最初的反应是因为我以前从未见过它。但是为1000个用户创建1000个JDBC连接似乎很愚蠢……每个连接有什么特别的地方吗？或者它们可以很容易地汇集在一起吗？如果您唯一关心的是性能，请使用连接池。我在你的问题历史记录中看到，你对Tomcat很熟悉，这里有一个链接如何做：@BalusC-我非常熟悉连接池，因为这是我通常使用的，或者让ORM库为我处理它。我以前从没见过这个。谢谢你提供的信息！线程安全问题是一个很好的切入点，而过时的连接则是一个很好的切入点。我想我只是想看看这种做法到底有多糟糕。