[
https://issues.apache.org/jira/browse/DERBY-3573?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13913300#comment-13913300
]
Mike Matrigali commented on DERBY-3573:
---------------------------------------
consider for 10.10 backport
> Argument checking for ResultSet.setFetchSize(int) is incorrect
> --------------------------------------------------------------
>
> Key: DERBY-3573
> URL: https://issues.apache.org/jira/browse/DERBY-3573
> Project: Derby
> Issue Type: Bug
> Components: JDBC, Network Client
> Affects Versions: 10.3.1.4, 10.3.2.1
> Reporter: Dyre Tjeldvoll
> Assignee: Nirmal Fernando
> Priority: Minor
> Labels: derby_triage10_8
> Fix For: 10.11.0.0
>
> Attachments: derby-3573-a.diff, derby-3573-b.diff,
> derby-3573-test.diff
>
>
> The requirement that the argument to ResultSet.setFetchSize(int) be less than
> Statement.getMaxRows() was dropped in Java 6/JDBC 4, (it is not present in
> the Java 6 javadoc, but can still be seen in the Java 5 javadoc).
> The reason why the client driver doesn't throw an exception in this case is
> because am.ResultSet incorrectly checks against ResultSet.maxRows_ and NOT
> am.Statement.getMaxRows(). So when am.Statement.setMaxRows(int) is called
> after a result set has already been created, am.ResultSet.setFechSize(int)
> will check against a stale value.
> The question is what to do about this. The client driver clearly has a bug,
> but should we fix it by duplicating the old behavior found in the embedded
> driver, or change both drivers to comply with latest spec which allows any
> non-negative value as argument to ResultSet.setFetchSize(int)?
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
