基于 Tomcat JNDI 和基于 Spring/Hibernate DS 的连接池有什么区别
我一直在研究连接池选项，但我不太清楚 Tomcat JNDI 连接池方法与 Spring/Hibernate 解决方案相比有何不同。
虽然可以使用 1 来实现池化、2、具体应用考虑到我们所面临的限制，我们使用 Tomcat 会更好。
阅读有关内容，有一些建议 坚持使用 Spring/Hibernate 。
每种方法之间是否有任何值得一提的显着差异？其他人对其中之一（或两者）的个人经验是什么？我已经成功使用 Spring/Hibernate 多年了。
I have been looking into connection pool options and it is somewhat unclear to me what the differences in Tomcat JNDI connection pool approach is, compared to the Spring/Hibernate solution to the same.
Whilst it's possible to achieve the pooling using either 1, 2, the specific application we have would lend itself better to us using Tomcat given the constraints we have.
Reading about, there is some suggestion to just stick with Spring/Hibernate.
Are there any notable differences worth mentioning between each approach? What are other's personal experience of one or the other (or both) - I have successfully been using Spring/Hibernate for years now.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
这两种方法是互补的，而不是相互排斥的。在生产系统中，Spring/Hibernate 之类的系统将从应用程序服务器获取对连接池的引用，以 javax.sql.DataSource 的形式，通常是通过在 JNDI 树上查找来获取。通常认为管理连接池及其连接是应用程序服务器的“工作”。
请记住，JNDI 只是注册共享对象的地方，它本身确实要求任何给定的连接池机制。应用服务器创建并配置池，应用程序（通过 Spring/Hibernate/其他）使用它。
然而，应用程序自己配置和管理连接池同样有效。不过，这确实意味着应用程序需要做更多的工作，同时减少对应用程序服务器的依赖。
The two approaches are complementary, not mutually exclusive. In production systems, the likes of Spring/Hibernate will obtain a reference to the connection pool from the appserver, in the form of a
javax.sql.DataSource, usually by looking for it on the JNDI tree. It generally considered to be the appserver's "job" to manage the connection pool and its connections.Remember, JNDI is just a place for registering objects for sharing, it does in itself mandate any given connection pool mechanism. The app server creates and configures the pool, and the applications (via Spring/Hibernate/whatever) use it.
It's just as valid, however, for the applications to configure and manage the connection pool themselves. This does mean a bit more work for the application, though, with less reliance on the appserver.