Re: [DISCUSS] JDBC exactly-once sink

2020-01-06 Thread Jingsong Li
Hi Piotr, We already have "JDBCUpsertOutputFormat". It is mainly proposed for Table/SQL API, but DataStream can use it to have the semantics of upsert. But it has weaker semantics than exactly once, and can only guarantee the final consistency. Best, Jingsong Lee On Mon, Jan 6, 2020 at 8:07 PM P

Re: [DISCUSS] JDBC exactly-once sink

2020-01-06 Thread Piotr Nowojski
Hi, Also +1 for using the XA. There might be scenarios where WAL could be a better option, but I think XA should be the default/first choice. If there will be a bigger demand for WAL, we can always provide it as an alternative. As Jingsong mentioned, with WAL I would be worried about batch like

Re: [DISCUSS] JDBC exactly-once sink

2020-01-06 Thread Jingsong Li
Thanks Roman for driving this. Although Upsert sink can bring some consistency guarantee to JDBC sink, users have strong requirements to append exactly-once sink too. +1 to use XA distribution transaction. For WAL, as far as my experience is concerned, writing JDBC in large quantities when check

[DISCUSS] JDBC exactly-once sink

2020-01-06 Thread Roman Khachatryan
Hi everyone, I'm currently working on exactly-once JDBC sink implementation for Flink. Any ideas and/or feedback are welcome. I've considered the following options: 1. Two-phase commit. This is similar to Kafka sink. XA or database-specific API can be used. In case of XA, each sink subtask acts a