apache/shardingsphere · error · SQLFeatureNotSupportedException

cancelRowUpdates

Error message

cancelRowUpdates

What it means

cancelRowUpdates() is a final method in AbstractUnsupportedOperationResultSet that unconditionally throws SQLFeatureNotSupportedException. Cancelling pending row edits presumes an updatable cursor, which the sharding ResultSet does not provide, and updateXxx methods on it are likewise unsupported.

Source

Thrown at jdbc/src/main/java/org/apache/shardingsphere/driver/jdbc/unsupported/AbstractUnsupportedOperationResultSet.java:115

    
    @Override
    public final void updateRow() throws SQLException {
        throw new SQLFeatureNotSupportedException("updateRow");
    }
    
    @Override
    public final void deleteRow() throws SQLException {
        throw new SQLFeatureNotSupportedException("deleteRow");
    }
    
    @Override
    public final void refreshRow() throws SQLException {
        throw new SQLFeatureNotSupportedException("refreshRow");
    }
    
    @Override
    public final void cancelRowUpdates() throws SQLException {
        throw new SQLFeatureNotSupportedException("cancelRowUpdates");
    }
    
    @Override
    public final void moveToInsertRow() throws SQLException {
        throw new SQLFeatureNotSupportedException("moveToInsertRow");
    }
    
    @Override
    public final void moveToCurrentRow() throws SQLException {
        throw new SQLFeatureNotSupportedException("moveToCurrentRow");
    }
    
    @Override
    public final boolean rowInserted() throws SQLException {
        throw new SQLFeatureNotSupportedException("rowInserted");
    }
    
    @Override

View on GitHub (pinned to e952770a21)

Solutions

1. Manage edit/rollback state in the application layer (edit a detached copy of the row; only issue SQL when the user confirms).
2. Request read-only concurrency so UI components do not attempt cursor edits.
3. If cursor editing is mandatory, perform it on a connection from the underlying physical datasource.

Example fix

// before
if (rowDirty) { rs.cancelRowUpdates(); } // throws

// after
// keep a local editable copy of row data; discard it to 'cancel'
editableRow = null; // nothing was ever sent to the DB

if (rs.getConcurrency() == ResultSet.CONCUR_READ_ONLY) {
    // pending edits live only in your app state; discard them there
}

try {
    rs.cancelRowUpdates();
} catch (SQLFeatureNotSupportedException e) {
    discardLocalEdits(); // application-level rollback of the edit buffer
}

When it happens

Trigger: Calling ResultSet.cancelRowUpdates() on a sharding ResultSet, typically from editable-table UIs or generic JDBC wrappers that roll back in-memory row edits before updateRow.

Common situations: Data-grid components (Swing JTable bindings, SWT/JFace, Apache Pivot) that manage dirty-row state via cancelRowUpdates; application code moved to the sharding JDBC URL without auditing cursor-edit calls.

Related errors

• updateRow
• deleteRow
• refreshRow
• moveToInsertRow
• moveToCurrentRow

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