Hibernate :What makes JDBC connections expensive?

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 ?

---

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.

---

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.