JDBC 中的连接是什么？
JDBC 中的连接对象是什么？ 如何维护此连接（我的意思是它是网络连接）吗？ 它们是 TCP/IP 连接吗？ 为什么每次创建连接都是一个成本高昂的操作？ 为什么这些连接在一段时间后变得陈旧，我需要刷新池？ 为什么我不能使用一个连接来执行多个查询？
What is a Connection Object in JDBC ? How is this Connection maintained(I mean is it a Network connection) ? Are they TCP/IP Connections ? Why is it a costly operation to create a Connection every time ? Why do these connections become stale after sometime and I need to refresh the Pool ? Why can't I use one connection to execute multiple queries ?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
这些连接是 TCP/IP 连接。 为了避免每次创建新连接时产生的开销，连接池可以动态扩展和收缩。 您可以使用一个连接进行多个查询。 我认为你的意思是把它释放到池中。 如果这样做，您可能会从池中取回相同的连接。 在这种情况下，执行一个或多个查询并不重要。
连接的成本是连接需要一些时间。 数据库为每个连接准备一些东西，例如会话等。 每次都必须这样做。 连接由于多种原因而变得陈旧。 最突出的是介于两者之间的防火墙。 连接问题可能会导致连接重置或可能出现简单的超时
These connections are TCP/IP connections. To not have to overhead of creating every time a new connection there are connection pools that expand and shrink dynamically. You can use one connection for multiple queries. I think you mean that you release it to the pool. If you do that you might get back the same connection from the pool. In this case it just doesn't matter if you do one or multiple queries
The cost of a connection is to connect which takes some time. ANd the database prepares some stuff like sessions, etc for every connection. That would have to be done every time. Connections become stale through multiple reasons. The most prominent is a firewall in between. Connection problems could lead to connection resetting or there could be simple timeouts
要添加到其他答案：
是的，您可以为多个查询重复使用同一连接。 这甚至是可取的，因为创建新连接的成本相当昂贵。
您甚至可以同时执行多个查询。 您只需为每个查询使用一个新的 java.sql.Statement/PreparedStatement 实例。 JDBC 使用语句来跟踪正在进行的查询，因此每个并行查询都需要自己的语句。 不过，您可以而且应该对连续查询重复使用语句。
To add to the other answers:
Yes, you can reuse the same connection for multiple queries. This is even advisable, as creating a new connection is quite expensive.
You can even execute multiple queries concurrently. You just have to use a new java.sql.Statement/PreparedStatement instance for every query. Statements are what JDBC uses to keep track of ongoing queries, so each parallel query needs its own Statement. You can and should reuse Statements for consecutive queries, though.
您的问题的答案是它们是由实现定义的。 JDBC 连接是公开方法的接口。 幕后发生的事情可以是任何提供界面的事情。 例如，考虑 Oracle 内部 JDBC 驱动程序，用于支持 java 存储过程。 同时查询不仅是可能的，而且或多或少是不可避免的，因为每个新连接的请求都会返回唯一的连接对象。 我不确定它内部是否使用 TCP/IP，但我对此表示怀疑。
因此，在不清楚您正在使用哪个 JDBC 实现的情况下，不应假设实现细节。
The answers to your questions is that they are implementation defined. A JDBC connection is an interface that exposes methods. What happens behind the scenes can be anything that delivers the interface. For example, consider the Oracle internal JDBC driver, used for supporting java stored procedures. Simultaneous queries are not only possible on that, they are more or less inevitable, since each request for a new connection returns the one and only connection object. I don't know for sure whether it uses TCP/IP internally but I doubt it.
So you should not assume implementation details, without being clear about precisely which JDBC implementation you are using.
因为我还不能发表评论，所以发布答案只是为了评论 Vinegar 的答案，在将连接返回到池时 setAutoCommit() 返回默认状态的情况不是强制性行为，也不应该被视为理所当然，也作为语句和结果集的关闭； 您可以看到它应该关闭，但是如果您不关闭它们，它们将随着连接的关闭而自动关闭。 不要认为这是理所当然的，因为它会占用某些版本的 jdbc 驱动程序的资源。
我们在 AS400 上的 DB2 数据库上遇到了严重的问题，需要事务隔离的人正在调用 connection.setAutoCommit(false)，并且在完成工作后，他们将此类连接返回到池（JNDI），而没有 connection.setAutoCommit(old_state)，因此当另一个线程获取此连接时从池中，插入和更新尚未提交，很长一段时间没有人能找出原因......
since I cannot comment yet, wil post answer just to comment on Vinegar's answer, situation with setAutoCommit() returning to default state upon returning connection to pool is not mandatory behaviour and should not be taken for granted, also as closing of statements and resultsets; you can read that it should be closed, but if you do not close them, they will be automatically closed with closing of connection. Don't take it for granted, since it will take up on your resources on some versions of jdbc drivers.
We had serious problem on DB2 database on AS400, guys needing transactional isolation were calling connection.setAutoCommit(false) and after finishing job they returned such connection to pool (JNDI) without connection.setAutoCommit(old_state), so when another thread got this connection from pool, inserts and updates have not commited, and nobody could figure out why for a long time...