It doesn't work when set properties for ShardingPreparedStatement.

[tristaZero]

Bug Report

For English only, other languages will not accept.

Before report a bug, make sure you have:

• Searched open and closed GitHub issues.
• Read documentation: ShardingSphere Doc.

Please pay attention on issues you submitted, because we maybe need more details.
If no response more than 7 days and we cannot reproduce it on current information, we will close it.

Please answer these questions before submitting your issue. Thanks!

Which version of ShardingSphere did you use?

4.0.0.RC3

Which project did you use? Sharding-JDBC or Sharding-Proxy?

Sharding-JDBC

Expected behavior

Actual behavior

When set queryTimeout property for ShardingPreparedStatement, it doesn't work.

Reason analyze (If you can)

Because when ShardingPreparedStatement is created, there is no actual PreparedStatement in ShardingPreparedStatement. Only when you call execute() or executeQuery(), PreparedStatement is created. So before execute() is called, any assignment for PreparedStatement will not work.

Steps to reproduce the behavior, such as: SQL to execute, sharding rule configuration, when exception occur etc.

One solution is to create PreparedStatement once ShardingPreparedStatement is created. You need to split function of initPreparedStatementExecutor() in ShardingPreparedStatement.
Here are related codes in ShardingPreparedStatement:

public ShardingPreparedStatement(final ShardingConnection connection, final String sql) {
        this(connection, sql, ResultSet.TYPE_FORWARD_ONLY, ResultSet.CONCUR_READ_ONLY, ResultSet.HOLD_CURSORS_OVER_COMMIT, false);
    }
---
@Override
    public ResultSet executeQuery() throws SQLException {
        ResultSet result;
        try {
            clearPrevious();
            shard();
            initPreparedStatementExecutor();
            MergeEngine mergeEngine = MergeEngineFactory.newInstance(connection.getRuntimeContext().getDatabaseType(), 
                    connection.getRuntimeContext().getRule(), sqlRouteResult, connection.getRuntimeContext().getMetaData().getTables(), preparedStatementExecutor.executeQuery());
            result = getResultSet(mergeEngine);
        } finally {
            clearBatch();
        }
        currentResultSet = result;
        return result;
    }
---
private void initPreparedStatementExecutor() throws SQLException {
        preparedStatementExecutor.init(sqlRouteResult);
        setParametersForStatements();
    }
---
In PreparedStatementExecutor.java
public void init(final SQLRouteResult routeResult) throws SQLException {
        setOptimizedStatement(routeResult.getShardingStatement());
        getExecuteGroups().addAll(obtainExecuteGroups(routeResult.getRouteUnits()));
        cacheStatements();
    }

Example codes for reproduce this issue (such as a github link).

[sunbufu]

After reading #2923, I agree with trista. Because init PreparedStatemen in advance is more direct, simpler, easier than cache some parameters.

[tristaZero]

@sunbufu Are u interested in this, so easy. As i said here

[sunbufu]

Yes, I'd like to do.

[tristaZero]

Waiting for your pr. 😃