[
https://issues.apache.org/jira/browse/FLINK-41101?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated FLINK-41101:
-----------------------------------
Labels: pull-request-available (was: )
> 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
> Labels: pull-request-available
> Fix For: jdbc-5.0.0
>
>
> Since FLINK-41060 a restarted exactly-once JdbcSink rolls back the prepared
> transactions of its own job. Those of an earlier job, after a restore from a
> savepoint or a retained checkpoint into a new job, stay prepared and keep
> their locks until someone rolls them back by hand. So do those of the same
> job at another parallelism.
> discoverAndRollbackOnRecovery was meant for this, but
> TransactionId.belongsTo() only matches TransactionId instances and drivers
> return their own Xid, so it never rolls anything back. Fixing that isn't
> enough: a transaction id doesn't name the sink, so a wider match also rolls
> back the transactions of another sink, or of a job that still runs.
> A restore at a lower parallelism doesn't get that far: it has failed with
> "more than one state to recover" since FLINK-25421 (3.2.0).
> We should add an optional transaction id prefix, as the KafkaSink has, and
> roll back the leftovers under it.
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
