MySQL在Tomcat中的最佳使用方式？
在 Tomcat 中使用 MySQL 哪种方法更好：
A) 只要会话有效，就为用户分配一个数据库连接。 [或者]
B）打开与数据库的连接，在每个请求到达服务器时，并在完成后关闭该连接。
C) 连接池。 [最佳答案]
Which one is better way of using MySQL in Tomcat :
A) assign a DB connection for user as long as it's session is valid. [OR]
B) open connection to DB, on every request come to server and when it's done close that.
C) Connection pool. [BEST answer]
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
推动力
在任何类型的请求-答复系统中（无论是 http、ftp 还是数据库调用），保持连接池开放以供客户端使用都是有意义的。在每个请求期间建立和拆除连接的成本很高（对于客户端和服务器而言），因此拥有一个池，多个线程可以从中“签出”连接以供其使用，这是一个很好的模式。
实现
JDBC API 提供了任意数量的数据库实现的包装器，这意味着调用者可以（大部分）不知道他们正在调用什么类型的数据库。这种抽象允许编码人员创建通用库，为任何类型的 JDBC 连接提供连接池。
这是关于连接池的 Sun 页面，以及 这是来自 MySQL 的。
由于调用者可能仅使用 JDBC 方法，因此
checkout看起来像是创建连接的请求，而checkin只是调用者关闭连接，即调用者不知道他们正在使用连接池，因为语义与使用单个连接创建/拆除解决方案没有区别。这是一件好事；这是真正的面向对象。库
那么有哪些库可以让这一切变得简单呢？
c3p0 - 这个库以每个人最喜欢的协议机器人命名提供连接池和准备好的语句池（我相信这是一个
PreparedStatement对象的对象池）。他们网站上的文档非常详尽。实际上，我在办公桌上打印了一份实体副本，因为我在调音时需要查阅它。所有配置都是以 JavaBeans 风格完成的，这使得使用它变得轻而易举。
它得到了广泛部署，并且能够承受压力。我使用它在多台机器上每秒处理数万甚至数十万个事务，并且每台机器有多个线程连接到多个数据库。
他们似乎有一个专门关于配置的附录 c3p0 由 Tomcat 使用，因此您可能希望检查一下。
DBCP — 命名不太有创意的 Apache DBCP（用于“数据库连接池” ）与 c3p0 执行几乎相同的操作。这个 讨论 似乎阻止了它的使用，认为 c3p0 得到了更积极的维护。我不太记得为什么我在上一个项目中选择 c3p0 而不是 DBCP（可能是熟悉），但如果您想看看 DBCP，请继续。
以下是一些有关 DBCP 的 Stack Overflow 问题：
我讨厌成为一个消极的 Nancy，但我不认为 DBCP 是你想要的。
BoneCP — 或许这个名字很有创意，但听起来有点奇怪。我从来没有用过它。作者说它真的很快，并且他可能是对的。它似乎是您所有选择中最不成熟的（至少暂时如此），但您应该尝试一下，看看它是否满足您的需求。
缺点
您将
DataSource包装在一些类似代理的其他类中，因此供应商特定的方法可能无法访问。这不是什么大问题：无论如何，您都不应该编写特定于供应商的数据库代码。Impetus
In any sort of request-reply system—be it http, ftp, or a database call—it makes sense to keep a pool of connections open for use in by a client. The cost of building and tearing down a connection during every single request is high (both for the client and for the server), so having a pool from which multiple threads may "check out" a connection for their use is a good pattern.
Implementation
The JDBC API provides a wrapper around any number of database implementations, meaning that callers can be (mostly) agnostic as to what sort of database they're calling. This abstraction has allowed coders to create generic libraries which provide connection pooling for any type of JDBC connection.
Here's the Sun page on connection pooling, and here's one from MySQL.
Since the caller is presumably using only JDBC methods, the
checkoutcan look like a request to create a connection, and thecheckinis just the caller closing the connection, i.e. the caller is unaware they're using connection pooling because the semantics are indistinguishable from using the single connection create/tear down solution. This is a good thing; this is real OO.Libraries
So what libraries are available to make this easy?
c3p0 — Named after everyone's favorite protocol droid, this library provides connection pooling and prepared statement pooling (I believe this is an object pool of
PreparedStatementobjects).The documentation on their website is pretty thorough. I've actually got a physical copy printed out in my desk because I need to consult it when I'm doing tuning. All configuration is done in a JavaBeans style which makes working with it a breeze.
It's widely deployed and stands up under pressure. I've used it for doing tens if not hundreds of thousands of transactions per second with multiple machines and multiple threads per machine connecting to multiple databases.
They appear to have an appendix specifically about configuring c3p0 for use by Tomcat, so you may wish to check that out.
DBCP — The less creatively-named Apache DBCP (for "Database Connection Pooling") does pretty much the same things as c3p0. This discussion seems to discourage its use, arguing that c3p0 is more actively maintained. I can't really remember why I chose c3p0 over DBCP for my last project (probably familiarity), but if you want to give DBCP a look, go ahead.
Here are some Stack Overflow questions about DBCP:
I hate to be a negative Nancy, but I don't think DBCP is what you want.
BoneCP — Perhaps creatively-named, but a bit weird sounding. I've never used it. The author says it's really fast, and he may be right. It seems the least mature—at least temporally—of all your options, but you should give it a go and see whether it meets your need.
Disadvantages
You're wrapping your
DataSourcein some proxy-like other class, so vendor-specific methods will likely not be accessible. This isn't a big deal: you shouldn't be writing vendor-specific DB code anyways.B），或
C）使用 连接池
B), or
C) use a connection pool