Hibernate：是什么让 JDBC 连接变得昂贵？
我读了一本关于 Hibernate 的书，发现了以下关于 Session 对象的陈述。
...但是如你所知，持有 JDBC 跨多个请求的连接 不推荐，因为它是一个 昂贵的资源。因此如果我们想要 维持 Hibernate 会话 很长的时期，使其跨越 多次请求重用 我们想要的持久化实例 断开会话的 JDBC 每个请求的连接无需 会议结束。我们可以使用 disconnect() 和 reconnect() 方法 在Session接口中支持 此类要求。
断开连接并重新连接 JDBC 是否会比保持原样更昂贵？到底是什么让资源变得昂贵？
I reading a book on Hibernate and I came across the following statement about the Session object.
....But as you know ,holding the JDBC
connections across multiple requests
is not recommended since it is an
expensive resource. Thus if we want to
maintain the Hibernate Session for
long periods, making it to span over
multiple requests for reusing
persistent instances we want to
disconnect the session's JDBC
connection for each request without
closing the session. We can use
disconnect() and reconnect() methods
in the Session interface to support
this kind of requirements.
Does disconnecting and reconnecting JDBC make it more expensive than keeping it as it is? What exactly makes a resource expensive ?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
在创建（建立）新连接时发生的跨多台计算机（如果您的数据库服务器托管在网络上）的握手过程使其成本高昂。这就是为什么建议使用连接池，或者在您的情况下使用会话。这可能包括主机查找、初始连接和后续控制命令。
The process of handshake spanning across multiple machines (if your db server is hosted over the network) which takes place on creating (establishing) a new connection makes it expensive. Thats why its recommended to use a connection pool, or in your case the session. This could include host lookup, initial connection, and subsequent control commands.
Session 接口上的断开连接和重新连接通常不会真正终止与数据库的连接。我们期望您使用的是池化提供程序，断开会话只会将实际的 JDBC 连接返回到池中供其他人使用。
对于大型 DBMS，打开连接和打开游标的开销远远高于 Java 应用服务器上的 Web 请求的开销。一台物理计算机作为应用服务器可以处理数百个并发 Web 请求，但作为 Oracle 11 服务器只能处理 30-50 个并发连接。 （只是个人/轶事经验，而不是真正的基准。）
如果您在整个“对话”周期中都坐在连接上，您的 Web 吞吐量将受到数据库资源的限制，而数据库资源的消耗速度往往比 Web 请求处理程序线程快得多。通过仅在需要时而不是在整个请求生命周期中保持连接，可以减少因等待数据库连接而被阻塞的 Web 请求线程。
The disconnect and reconnect on the Session interface do not generally actually terminate the connection to the database. The expectation is you're using a pooled provider and disconnecting the session just returns the actual JDBC connection to a pool for someone else to use.
For a large scale DBMS the overhead of open connections and open cursors is far higher than the overhead for a web request on a java app server. A physical computer that can handle hundreds of simultaneous web requests as an app server, could only handle maybe 30-50 simultaneous connections as an Oracle 11 server. (just personal/anecdotal experience, not a real benchmark.)
If you sit on a connection for an entire 'conversation' cycle, your web throughput is limited to your database resources, which again, tend to exhaust way faster than web request handler threads. By only holding the connection for as long as you need it, and not the entire request lifecycle, fewer web request threads sit around blocked on waiting for a database connection.
这取决于资源是什么。但对于数据库连接之类的事情，它被认为是昂贵的，因为为了做到这一点，机器必须分配套接字、内存、文件和其他资源以保持您和数据库之间的连接打开。设置连接还需要相当长的时间（从计算机的角度来看），因此不断打开和关闭它会减慢速度。
最好的折衷方案是使用连接池。因此，一个连接在多个需要它的事物之间共享。这节省了大量的时间和资源，并且考虑到在大多数情况下不会经常使用连接，因此共享可以更好地利用它。
It depends on what the resource is. But with things like database connections, it's regarded as expensive because in order to do it, the machine has to allocate sockets, memory, files and other resources to keeping the connection between you and the database open. It also takes considerable (from a computers point of view) time to setup the connection so constantly opening and closing it would slow you down.
The best compromise is to use a connection pool. Thus one connection is shared between multiple things that require it. This saves a lot of time and resources and considering that for most cases a connection isn't being used constantly, sharing better utitises it.