apache/shardingsphere · error · IllegalStateException

Can not get value from parameter sets.

Error message

Can not get value from parameter sets.

What it means

IllegalStateException thrown from BatchPreparedStatementExecutor.getParameterSets when no BatchExecutionUnit in batchExecutionUnits matches the given JDBCExecutionUnit by datasource+SQL. It signals an internal inconsistency between the routing result (execution units) and the batch parameter groups collected from addBatch() calls — a library-side invariant break, not normal input validation.

Source

Thrown at jdbc/src/main/java/org/apache/shardingsphere/driver/executor/engine/batch/preparedstatement/BatchPreparedStatementExecutor.java:243

        return Collections.emptyList();
    }
    
    private Optional<JDBCExecutionUnit> findJDBCExecutionUnit(final Statement statement, final ExecutionGroup<JDBCExecutionUnit> executionGroup) {
        for (JDBCExecutionUnit each : executionGroup.getInputs()) {
            if (each.getStorageResource().equals(statement)) {
                return Optional.of(each);
            }
        }
        return Optional.empty();
    }
    
    private List<List<Object>> getParameterSets(final JDBCExecutionUnit executionUnit) {
        for (BatchExecutionUnit each : batchExecutionUnits) {
            if (isSameDataSourceAndSQL(each, executionUnit)) {
                return each.getParameterSets();
            }
        }
        throw new IllegalStateException("Can not get value from parameter sets.");
    }
    
    /**
     * Clear.
     */
    public void clear() {
        executionGroupContext.getInputGroups().clear();
        batchCount = 0;
        batchExecutionUnits.clear();
    }
}

View on GitHub (pinned to e952770a21)

Solutions

1. Ensure every addBatch() call on a PreparedStatement uses the same SQL and only parameters vary; never interleave different statements.
2. Call clearBatch() before starting a new batch cycle on a reused statement.
3. Do not share a single PreparedStatement/connection across threads for batch execution.
4. If SQL and datasources are consistent and it still fails, capture the statement SQL, parameter sets, and routing config and report it as a ShardingSphere bug; try upgrading to the latest patch release.

Example fix

// before
stmt.addBatch("INSERT INTO t VALUES (?)");
stmt.addBatch("INSERT INTO u VALUES (?)"); // different SQL in one batch
stmt.executeBatch();
// after
stmt.addBatch(); stmt.addBatch(); // same SQL via PreparedStatement, params only
stmt.executeBatch();

// one statement, one SQL, params only
if (batchSqlVariants > 1) throw new IllegalArgumentException("mixed SQL in batch");

catch (IllegalStateException ex) { rollbackTx(); clearBatch(); rethrowWithDiagnostics(); }

When it happens

Trigger: Executing a batched PreparedStatement via JDBC driver when the rerouted JDBCExecutionUnit's dataSourceName/SQL pair does not isSameDataSourceAndSQL-match any collected BatchExecutionUnit — e.g. routing changed between addBatch and executeBatch, or inconsistent parameter metadata across batch rows.

Common situations: Mixing different SQL statements or different datasources in one batch object; reuse of a statement after clearBatch in a partial state; version regressions in the driver's batch routing; concurrency bugs where a statement is shared across threads.

Related errors

• 0
• setFetchSize
• addBatch sql in PreparedStatement
• Invalid statement handle: %d
• 6

AI-assisted analysis of apache/shardingsphere@e952770a21 (2026-08-14). Data as JSON: /api/errors/87254a1bf0ad05ac. Report an issue: GitHub.