Why MySQL’s MysqlConnectionPoolDataSource Isn’t a Real Connection Pool (And How to Use It)

In a previous post the author built a custom MySQL connection pool using Apache Commons‑Pool2 and modeled the API after GORM, hiding borrow and return operations from users.

While recording a video, IntelliJ suggested the class com.mysql.cj.jdbc.MysqlConnectionPoolDataSource, which seemed to match the desired functionality.

Documentation for this class is sparse and the official MySQL docs give the impression that it is not the recommended way to manage connections, especially in a Spring environment where more robust pooling solutions exist. However, for lightweight, script‑driven testing the author wanted to evaluate it.

What the class actually does

The name is misleading: the implementation does not pool connections for reuse. Each call to obtain a connection creates a new physical connection, and idle connections are simply closed after a configurable timeout via the close() method. This behaviour defeats the primary goal of a connection pool, which is to reduce the overhead of repeatedly opening and closing connections.

Simple Groovy usage example

package com.funtest.groovytest

import com.funtester.frame.SourceCode
import com.mysql.cj.jdbc.MysqlConnectionPoolDataSource

class MysqlPoolTe extends SourceCode {
    public static void main(String[] args) {
        def query = "select * from testers limit 2;"
        def source = new MysqlConnectionPoolDataSource()
        source.setServerName("localhost")
        source.setPort(3306)
        source.setUser("root")
        source.setPassword("root123456")
        source.setDatabaseName("funtester")
        source.setAllowMultiQueries(true)
        def connection = source.getPooledConnection()
        def statement = connection.getConnection().createStatement()
        while (true) {
            sleep(1)
            def result = statement.executeQuery(query)
            while (result.next()) {
                output result.getString("name")
            }
        }
    }
}

A common pitfall is the presence of both setURL() and setUrl() methods, which are functionally identical and exist for backward compatibility. After setting the URL, the setDatabaseName() call may have no effect, so the author avoided using these methods in the example.

Performance test observations

The author ran a test that spawned many threads. Although thousands of threads were created, only a few connections were active at any time; connections were reclaimed after a few seconds, leading to a high rate of connection creation.

Based on these findings, the author decided not to adopt com.mysql.cj.jdbc.MysqlConnectionPoolDataSource as a true pool and will continue improving the custom pool implementation.