[ 
https://issues.apache.org/jira/browse/FLINK-21488?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Roman Khachatryan resolved FLINK-21488.
---------------------------------------
    Resolution: Fixed

Merged into master as `cb987a114a5a496ef3399507a547f83140c20d9f` .. 
`46546c4887c226a32da8ecfaee42ede0749ef4b6`.

Thanks for the fix [~mobuchowski] !

> Jdbc XA sink - XID generation conflicts between jobs
> ----------------------------------------------------
>
>                 Key: FLINK-21488
>                 URL: https://issues.apache.org/jira/browse/FLINK-21488
>             Project: Flink
>          Issue Type: Bug
>          Components: Connectors / JDBC
>    Affects Versions: 1.13.0
>            Reporter: Maciej Obuchowski
>            Assignee: Maciej Obuchowski
>            Priority: Major
>              Labels: pull-request-available
>             Fix For: 1.13.0
>
>
> I'm using Flink 1.13's JDBC XA sink to write data to oracle DB using exactly 
> once semantics.
> I want to have two jobs doing this. One is working right now. When starting 
> second one, I encountered errors:
> org.apache.flink.util.FlinkRuntimeException: unable to start XA transaction, 
> xid: 201:0600000000000000:9b1d1b84e8ce79bb, error -3: resource manager error 
> has occurred. [XAErr (-3): A resource manager error has occured in the 
> transaction branch. ORA-2079 SQLErr (0)]
> Oracle description:
> ORA-02079: cannot join a committing distributed transaction
>     Cause: Once a transaction branch is prepared, no more new transaction 
> branches are allowed to start, nor is the prepared transaction branch allowed 
> to be joined.
>     Action: Check the application code as this is an XA protocol violation.
> I've looked at the implementation of XID generation and noticed following 
> line:
> private transient byte[] gtridBuffer; // globalTransactionId = checkpoint id 
> (long)
> My hypothesis is that second job generated xid that referred to global 
> transaction id that the first job created. If I'm right, then I'd suppose fix 
> would rely on embedding part of job id inside of gtridBuffer.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Reply via email to