[ 
https://issues.apache.org/jira/browse/FLINK-9794?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16540045#comment-16540045
 ] 

ASF GitHub Bot commented on FLINK-9794:
---------------------------------------

Github user sihuazhou commented on a diff in the pull request:

    https://github.com/apache/flink/pull/6301#discussion_r201676322
  
    --- Diff: 
flink-connectors/flink-jdbc/src/main/java/org/apache/flink/api/java/io/jdbc/JDBCOutputFormat.java
 ---
    @@ -111,110 +134,117 @@ public void writeRecord(Row row) throws IOException 
{
                if (typesArray != null && typesArray.length > 0 && 
typesArray.length != row.getArity()) {
                        LOG.warn("Column SQL types array doesn't match arity of 
passed Row! Check the passed array...");
                }
    -           try {
    +           synchronized (this) {
    --- End diff --
    
    Why do we need synchronized this?


> JDBCOutputFormat does not consider idle connection and multithreads 
> synchronization
> -----------------------------------------------------------------------------------
>
>                 Key: FLINK-9794
>                 URL: https://issues.apache.org/jira/browse/FLINK-9794
>             Project: Flink
>          Issue Type: Bug
>          Components: Streaming Connectors
>    Affects Versions: 1.4.0, 1.5.0
>            Reporter: wangsan
>            Priority: Major
>              Labels: pull-request-available
>
> Current implementation of  JDBCOutputFormat has two potential problems: 
> 1. The Connection was established when JDBCOutputFormat is opened, and will 
> be used all the time. But if this connection lies idle for a long time, the 
> database will force close the connection, thus errors may occur.
> 2. The flush() method is called when batchCount exceeds the threshold, but it 
> is also called while snapshotting state. So two threads may modify upload and 
> batchCount, but without synchronization.
> We need fix these two problems to make JDBCOutputFormat more reliable.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Reply via email to