apache/seatunnel · warning

The JDBC source statement returned no connection. Closing th

Error message

The JDBC source statement returned no connection. Closing the cached connection to avoid reusing an unknown transaction.

What it means

JdbcInputFormat.getStatementConnection() extracts the Connection from the active JDBC statement. If the driver returns null (statement already closed or driver misbehavior), the format logs this warning and closes the cached connection via chunkSplitter to avoid reusing a connection with an unknown transaction state. It then returns null, which callers must treat as 'no valid connection'.

Source

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

            } finally {
                statement = null;
            }
        }

        hasNext = false;
        splitTableSchema = null;
        splitTableId = null;
        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) {

View on GitHub (pinned to cf67b549a7)

Solutions

1. Inspect driver behavior/version; upgrade to one that reliably returns the connection from the statement.
2. Check for earlier exceptions or connection-close calls that invalidated the statement before this point.
3. Handle the null return: treat it as connection loss and let the source retry/reopen rather than reusing the connection.
4. Review auto-commit/transaction config so the cached connection is not left in an unknown transaction state.

Example fix

// before
Connection conn = format.getStatementConnection();
conn.setReadOnly(true);
// after
Connection conn = format.getStatementConnection();
if (conn != null && !conn.isClosed()) {
    conn.setReadOnly(true);
}

// Guard before using the returned connection
if (conn == null || conn.isClosed()) {
    LOG.warn("No usable connection — request a retry/reopen");
    return;
}

boolean isUsable(Connection c) {
    try { return c != null && !c.isClosed(); } catch (SQLException e) { return false; }
}

try {
    Connection c = format.getStatementConnection();
    if (c == null) { /* connection discarded; trigger task retry */ }
} catch (Exception e) { /* fail task so framework recreates the connection */ }

When it happens

Trigger: Calling connection/getStatementConnection() when the statement is non-null but statement.getConnection() returns null — typically after the underlying connection was closed or the statement was invalidated by the driver.

Common situations: Driver-specific behavior after connection reset; transactional reads where a previous failure left the cached connection in an unknown state; network drop between statement creation and connection retrieval.

Related errors

• NO_SUITABLE_DRIVER
• NO_SUITABLE_DRIVER
• NO_SUITABLE_DRIVER
• CREATE_DRIVER_FAILED
• Failed to get the JDBC source connection from the current st

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