0

I have a project in which I used HikariCP for JDBC connection pooling. And HikariCP works just great for my needs. It also logs the stats of the pool like below.

2014-12-03 10:16:08 DEBUG HikariPool:559 - Before cleanup pool stats loginPool (total=8, inUse=0, avail=8, waiting=0)
  2014-12-03 10:16:08 DEBUG HikariPool:559 - After cleanup pool stats loginPool (total=7, inUse=1, avail=7, waiting=0)

Just for experimental purposes I closed all the MySQL connections for the configured database using MySQL Workbench. But, still I see HikariCP logging the stats like before though there are no actual connections to the database. When there was a request for connection it immediately established the connections(initial 8), so everything works great.

So, my question is how does these connections are managed or implemented? I think the reason why HikariCP logs stats, as if there were connections, is because it has valid in memory references to connections, which are actually non existent(with database).

Is my understanding correct?

phoenix
  • 985
  • 3
  • 17
  • 38

2 Answers2

1

The connection pool created 8 connections at startup. You say you disconnected them using the workbench. Most connection pools won't know the connection is disconnected until it gets used.

Your assumption is correct. You manually killed the connections but the pool has a handle to 8 sockets which it assumes are connected. Given time your connection pool may have checked the connections for validity and attempted to reconnect them. I can't speak for HikariCP but this is what modern connections pools do.

slipperyseal
  • 2,728
  • 1
  • 13
  • 15
  • Thank you. But, I was mostly interested in internal working. How these are managed? – phoenix Dec 03 '14 at 05:33
  • Um.. explain "managed"? The purpose of a connection pool is to abstract actual JDBC connections from the ones returned by the pool. They can do things such as creating prepared statements and then try to execute subsequent statements on the same connection where possible. There may not be a 1 to 1 relationship between Connection objects your code sees and the actual connections, depending on how the pool wants to optimise them. "How are they managed?" is a big question. – slipperyseal Dec 03 '14 at 06:13
  • Yes. I realize my mistake. The question in fact is very broad. – phoenix Dec 03 '14 at 06:17
  • A JDBC connection pool won't deal with native code and sockets. The JDBC driver might, but the pool simply sits in between the driver. The Connection interface returned by a JDBC driver is the same as the one returned by the connection pool. So it passes the queries onto the driver as though they had come from your code directly. – slipperyseal Dec 03 '14 at 06:24
1

When you close the connections using MySQL Workbench, you are closing them on the server end. On the JDBC (client) side, the previously established connections will remain in existence until the client code attempts to use them. At that point, they will be found to be "broken"; i.e. the client will get exceptions when it tries to use them.

The client-side JDBC Connection objects only get closed or recycled when they are returned to the connection pool by your Java application code.

Stephen C
  • 698,415
  • 94
  • 811
  • 1,216
  • Just being curious. I already admitted that the question is broad. But, is there any source that I can use to understand the link between the Java Heap object and External Connection? – phoenix Dec 03 '14 at 06:49
  • 1
    The source code for both MySQL Connector/J and HikariCP is what you need. Drilling down into the JVM source code is unlikely to tell you anything relevant. (At that level, this is just mapping onto sockets and streams, and there is unlikely to be any "management" going on that is relevant to what you observe at the JDBC client API.) – Stephen C Dec 03 '14 at 06:56