, not finding finger to point, but just illustrate the logic flow.
I think the root cause is the fact that a prepare call can specify the maxRowCount and if that prepared statement is re-executed with a higher maxRowCount (or no limit) the results will be invalid. Do you agree with the root cause?
No, if setting the maxRowCount will do a re-prepare, the execute will always get the latest settings (plus a new statement at the server end), so the above scenario would not happen.
I believe that the only time a prepare request occurs with a row limit is a prepare-and-execute call (i.e. caused by Statement.executeQuery). Do you believe that to be true? If that is true, then it will be impossible to re-execute the prepare with a different row limit.
I think what missing here is that we are trying to set the maxRowCount during prepare, instead of during execute. To fulfill JDBC contract for setting maxRowCount, even for PreparedStatment, I think is good to support RPC call that can
prepareAndExecute can end up calling prepare and then execute, we can also choose to combine the call and indicating which task under the method argument, but I prefer having separate RPC which is much cleaner.
I found at least one place where you were checking 'parameter > 0'
I think that would be in the JdbcMeta.prepare, the original check is in prepareAndExecute, where maxRowCount has been change by following code:
final int maxRowCount1 = maxRowCount <= 0 ? -1 : maxRowCount;
But I agree, prepare should takes 0, but for JdbcMeta.prepare case it is checking condition whether to call setMaxRows, not to pass in for meta.prepare. Should the above code be in setMaxRows instead of having to convert in every execute call?