apache/seatunnel · error · JdbcConnectorException

COMMON_WRITER_OPERATION_FAILED

COMMON_WRITER_OPERATION_FAILED

Error message

unable to open JDBC sink aggregated committer

What it means

JdbcSinkAggregatedCommitter.tryOpen() opens the XA facade used by the committer; if xaFacade.open() throws, this WRITER_OPERATION_FAILED error is thrown. The committer cannot commit or abort prepared transactions without an open XA connection.

Source

Thrown at seatunnel-connectors-v2/connector-jdbc/src/main/java/org/apache/seatunnel/connectors/seatunnel/jdbc/sink/JdbcSinkAggregatedCommitter.java:72

    private final JdbcSinkConfig jdbcSinkConfig;

    public JdbcSinkAggregatedCommitter(JdbcSinkConfig jdbcSinkConfig) {
        this.jdbcSinkConfig = jdbcSinkConfig;
    }

    @Override
    public void init() {
        this.xaFacade =
                XaFacade.fromJdbcConnectionOptions(jdbcSinkConfig.getJdbcConnectionConfig());
        this.xaGroupOps = new XaGroupOpsImpl(xaFacade);
    }

    private void tryOpen() throws IOException {
        if (!xaFacade.isOpen()) {
            try {
                xaFacade.open();
            } catch (Exception e) {
                throw new JdbcConnectorException(
                        CommonErrorCodeDeprecated.WRITER_OPERATION_FAILED,
                        "unable to open JDBC sink aggregated committer",
                        e);
            }
        }
    }

    @Override
    public List<JdbcAggregatedCommitInfo> commit(
            List<JdbcAggregatedCommitInfo> aggregatedCommitInfos) throws IOException {
        return commitPreparedTransactions(aggregatedCommitInfos);
    }

    /**
     * Reconciles checkpoint XIDs with the resource manager using commit-order evidence. Checkpoint
     * XIDs from the first still-prepared transaction onward must all be present in the recovery
     * scan and are replayed strictly. An all-absent batch is treated as already resolved, while an
     * absent prefix before a still-prepared suffix is treated as already resolved only after that

View on GitHub (pinned to cf67b549a7)

Solutions

  1. Check the cause for the JDBC connection error (URL, credentials, network)
  2. Verify DB connectivity from the coordinating node at commit time
  3. Confirm the user retains XA privileges and DB connection limits are not exhausted
  4. Rerun commit from checkpoint; commits are idempotent via XA recovery

Example fix

// before
"url":"jdbc:postgresql://db:5432/app" // max_connections exhausted
// after: increase max_connections or pool size in config
Defensive patterns

Strategy: validation

Validate before calling

// pre-check commit-time connectivity
try (Connection c = DriverManager.getConnection(url, user, pass)) { assert c.isValid(5); }

Try / catch

try { committer.commit(xids); } catch (JdbcConnectorException e) { if (isConnectionError(e.getCause())) retryAfterReconnect(); else throw e; }

Prevention

When it happens

Trigger: tryOpen is called from restoreCommit, commitPreparedTransactions, and abort; any Exception from xaFacade.open() (failed XA connection creation) triggers it.

Common situations: Database unreachable at commit time; credentials changed or expired between write and commit phases; DB exhausted connection limit; XA privileges missing for the committer's user.

Related errors


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