Hibernate: What is the connection pool and why is the default one unsuitable for production?

Question

I\'m very unfamiliar with Hibernate and have just started working on a web app that uses it with a MySQL database. I notice that the community documentation tutorial states:

Answer 1

When you are dealing with a standalone application there are a couple of pooling managers which have not been maintained by Hibernate. Hibernate never favored one explicit. Over the years many have come and faded again. It is really hard to judge in the end which are best. It is good to check and compare by yourself the projects and how active these are still.

Here are some recent (2017) pooling recommendations for standalone applications in alphabetic order:

C3P0 http://www.mchange.com/projects/c3p0/

Hikari https://github.com/brettwooldridge/HikariCP

Vibur http://www.vibur.org/

Answer 2

The default connection pool in hibernate is c3p0 named after the star wars character. But hibernate supports also proxool and used to also advertise apache dbcp. For a while DBCP was dormant and fell out of grace.

C3P0 is actually used in production in many projects. Although it is sometimes found to behave poorly at peak time. There are several alternatives. Like for instance the new connection pool included in Tomcat 7. I haven't tested it yet though, but heard some positive feedbacks about it.

Answer 3

What is the connection pool and why is the default one unsuitable for production? Can someone elaborate on this?

Connection pooling is a technique to open/prepare/close connections. A connection pooling mechanism is a piece of software (component), to which you delegate the function of managing connections. Your application would just ask for a connection, use it, and deliver it back to the pool. The component is responsible for opening N connections and leave them ready for when your application asks. If a connection is stale, the pooling mechanism would then close it and reopen a new one. This represents a better usage of connections, as you don't need to wait for the connection to be established during the actual execution of your code and you don't have to worry about stale connections.

Hibernate doesn't really ship any real connection pooling mechanism. It provides an internal connection manager, which is very rudimentary. The reason is simple: almost (if not all) Application Servers (like JBoss AS) and Servlet Containers (like Tomcat) provides a connection pooling mechanism by default. Thus, your application don't have to worry about the details about it. It just asks the AS for a connection.

In my opinion, there are only two cases where you need to worry about connection pooling:

1. You are dealing with a standalone application (which doesn't run inside a container)
2. You are really expert in connection pooling and none of the existing suits your needs.

But in my experience, most people that uses an "external" connection pooling do so for lack of knowledge about connection pooling and lack of knowledge about their container.