alibaba/druid · warning · SQLException

not support

Error message

not support

What it means

Thrown unconditionally by DruidPooledStatement.setPoolable(false). Druid's pooled statement always returns isPoolable()==false and refuses to enable pooling via setPoolable(true is a no-op, false throws), because Druid manages statement pooling itself via its PreparedStatement cache and does not delegate the JDBC poolable hint to the underlying driver. The error is a deliberate guard, not a runtime fault.

Source

Thrown at core/src/main/java/com/alibaba/druid/pool/DruidPooledStatement.java:871

        try {
            return stmt.getResultSetHoldability();
        } catch (Throwable t) {
            throw checkException(t);
        }
    }

    @Override
    public final boolean isClosed() throws SQLException {
        return closed;
    }

    @Override
    public final void setPoolable(boolean poolable) throws SQLException {
        if (poolable) {
            return;
        }

        throw new SQLException("not support");
    }

    @Override
    public final boolean isPoolable() throws SQLException {
        return false;
    }

    public String toString() {
        return stmt.toString();
    }

    public void closeOnCompletion() throws SQLException {
        stmt.closeOnCompletion();
    }

    public boolean isCloseOnCompletion() throws SQLException {
        return stmt.isCloseOnCompletion();
    }

View on GitHub (pinned to fa8dc99126)

Solutions

1. Remove the setPoolable(false) call — it has no useful effect under Druid and is what triggers the exception.
2. If a framework calls it, configure the framework to skip statement poolable hints, or wrap with a Statement that swallows the unsupported operation.
3. Control statement caching through Druid's own configuration (poolPreparedStatements, maxOpenPreparedStatements) instead of the JDBC poolable API.

Example fix

// before
Statement st = conn.createStatement();
st.setPoolable(false); // throws 'not support'

// after
Statement st = conn.createStatement();
// do not call setPoolable; Druid manages caching itself
// configure in DataSource: poolPreparedStatements=true; maxOpenPreparedStatements=20

// Do not call setPoolable(false) on Druid statements.
if (statement instanceof DruidPooledStatement) {
    // skip; Druid does not support disabling poolable
} else {
    statement.setPoolable(false);
}

public static boolean supportsSetPoolable(Statement s) {
    return !(s instanceof DruidPooledStatement);
}

try {
    stmt.setPoolable(false);
} catch (SQLException e) {
    if ("not support".equals(e.getMessage())) {
        // expected under Druid; ignore
    } else throw e;
}

When it happens

Trigger: Calling statement.setPoolable(false) on a DruidPooledStatement (or any Statement obtained from a Druid connection). ORM frameworks or generic JDBC wrappers that disable poolability on statements will hit this.

Common situations: Spring/JPA, Hibernate, or MyBatis wrappers that call setPoolable(false) on result-bearing statements; migration from another pool (HikariCP/DBCP) that tolerated the call; code copied from tutorials setting poolable hints.

Related errors

• statement is closed
• Not supported by HighAvailableDataSource.
• Not supported by DruidDataSource
• xa not support dbType : {dbTypeName}
• create driver instance error, driver className '{className}'

AI-assisted analysis of alibaba/druid@fa8dc99126 (2026-08-14). Data as JSON: /api/errors/ba5b26b7e7a00b67. Report an issue: GitHub.