[
https://issues.apache.org/jira/browse/FLINK-41101?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18131560#comment-18131560
]
Martijn Visser commented on FLINK-41101:
----------------------------------------
FLINK-41060 makes this reachable on every restart before the first completed
checkpoint: the writer starts the same xid again and fails with XAER_DUPID
(-8). The FLINK-41060 PR rolls back that one transaction when a writer starts
without state. Once discoverAndRollbackOnRecovery works, that rollback can go.
> discoverAndRollbackOnRecovery never rolls back a transaction against a real
> driver
> ----------------------------------------------------------------------------------
>
> Key: FLINK-41101
> URL: https://issues.apache.org/jira/browse/FLINK-41101
> Project: Flink
> Issue Type: Bug
> Components: Connectors / JDBC
> Reporter: Martijn Visser
> Assignee: Martijn Visser
> Priority: Blocker
> Fix For: jdbc-5.0.0
>
>
> XaTransaction.recoverAndRollback() filters the xids from XAResource.recover()
> with TransactionId.belongsTo(xid), which returns false unless the xid is a
> TransactionId. Drivers return their own Xid class, so with
> JdbcExactlyOnceOptions.isDiscoverAndRollbackOnRecovery() (the default)
> nothing is ever rolled back. The downscale check in belongsTo
> ({{numberOfSubtasks < tXid.subtaskId}}) also looks off by one.
> When fixing it, the rollback must skip the transactions of checkpoints before
> the restored one: since FLINK-41060 the committer commits a transaction after
> the next checkpoint completed, and the CommitterOperator restores and commits
> those. Rolling them back on writer restore would lose their data. Only
> transactions with a checkpoint id at or above the restored checkpoint id
> belong to the writer.
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
