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 thatView on GitHub (pinned to cf67b549a7)
Solutions
- Check the cause for the JDBC connection error (URL, credentials, network)
- Verify DB connectivity from the coordinating node at commit time
- Confirm the user retains XA privileges and DB connection limits are not exhausted
- 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
- Check DB connection limits and pool sizing
- Re-verify credentials before commit phase (they may rotate)
- Grant XA privileges to the committer user
- Run commits on nodes with proven DB connectivity
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
- CONNECT_FAILED
- COMMON_WRITER_OPERATION_FAILED
- Failed to get connection, interrupted while doing another at
- Get connection failed after retry times
- Failed to discover remaining tables to capture
AI-assisted analysis of apache/seatunnel@cf67b549a7 (2026-09-10).
Data as JSON: /api/errors/dd4c276fa226de9f.
Report an issue: GitHub.