Failed to get the JDBC source connection from the current st

Error message

Failed to get the JDBC source connection from the current statement. Closing the cached connection to avoid reusing an unknown transaction.

What it means

JdbcInputFormat.getStatementConnection() calls statement.getConnection(); if the driver throws SQLException there, the format logs this warning (with the exception) and closes the cached connection through chunkSplitter, returning null so the invalid connection/transaction is never reused. It signals the JDBC source has lost access to its statement's connection.

Source

Thrown at seatunnel-connectors-v2/connector-jdbc/src/main/java/org/apache/seatunnel/connectors/seatunnel/jdbc/internal/JdbcInputFormat.java:195

        finishReadTransaction(connection);
    }

    private Connection getStatementConnection() {
        if (statement == null) {
            return null;
        }
        try {
            Connection connection = statement.getConnection();
            if (connection == null) {
                LOG.warn(
                        "The JDBC source statement returned no connection. "
                                + "Closing the cached connection to avoid reusing an unknown "
                                + "transaction.");
                chunkSplitter.close();
            }
            return connection;
        } catch (SQLException e) {
            LOG.warn(
                    "Failed to get the JDBC source connection from the current statement. "
                            + "Closing the cached connection to avoid reusing an unknown "
                            + "transaction.",
                    e);
            chunkSplitter.close();
            return null;
        }
    }

    private void finishReadTransaction(Connection connection) {
        try {
            finishReadTransaction(connection, configuredAutoCommit);
        } catch (SQLException e) {
            LOG.warn(
                    "Failed to finish the JDBC source read transaction. "
                            + "Closing the connection to avoid leaving or reusing an idle "
                            + "transaction.",
                    e);

View on GitHub (pinned to cf67b549a7)

Solutions

Enable connection keepalive/validation and adjust server-side timeouts (e.g., MySQL wait_timeout) above job durations.
Retry the read task — SeaTunnel will recreate the connection; ensure restart strategy is configured.
Upgrade/replace the JDBC driver if it throws spuriously from getConnection().
Check prior errors in logs that closed the statement before this call.

Example fix

// before
jdbc_url=jdbc:mysql://host:3306/db?useSSL=true
// after (keepalive above idle timeout)
jdbc_url=jdbc:mysql://host:3306/db?useSSL=true&autoReconnect=true&socketTimeout=3600000&connectTimeout=60000

Defensive patterns

Strategy: retry

Validate before calling

// Validate before reuse
if (conn.isClosed() || !conn.isValid(5)) {
    LOG.warn("Connection invalid before read — reopening");
}

Try / catch

try {
    Connection c = format.getStatementConnection();
} catch (SQLException e) {
    // logged internally; allow the source task to retry and recreate the connection
    throw new IOException(e);
}

Prevention

Raise MySQL wait_timeout / TCP idle limits above read duration
Enable connection validation and keepalive in the JDBC URL
Ensure job restart/retry strategy is enabled for transient connection loss

When it happens

Trigger: connection()/getStatementConnection() when statement.getConnection() throws SQLException — statement already closed, connection aborted by the driver, or driver-level communication failure.

Common situations: Long-running source reads hitting network timeouts or server-side connection kills (wait_timeout); drivers closing statements after errors; transactional reads across checkpoint restore where the cached connection is stale.

Related errors

AI-assisted analysis of apache/seatunnel@cf67b549a7 (2026-09-10). Data as JSON: /api/errors/00d9470615c33e5a. Report an issue: GitHub.