Re: JDBC stored procs doc patch

Nic wrote:
>
>>>+<programlisting>
>>>+Statement st = db.createStatement();
>>>+// Turn use of the cursor on.
>>>+st.setFetchSize(50);
>>>+ResultSet rs = st.executeQuery("SELECT * FROM mytable");
>>>+while (rs.next()) {
>>>+   System.out.print("a row was returned.");
>>>+}
>>>+rs.close();
>>>+// Turn the cursor off.
>>>+st.setFetchSize(0);
>>>+ResultSet rs = st.executeQuery("SELECT * FROM mytable");
>>>+while (rs.next()) {
>>>+   System.out.print("many rows were returned.");
>>>+}
>>>+rs.close();
>>>+// Close the statement.
>>>+st.close();
>>>+</programlisting>
>>>+     </para>
>>>+
>>>+
>>
>>
>>I do not understand what the example is supposed to show.  The fetch
>>size is transparent to the user (it is just a hint to the driver about
>>what should be the best strategy) so you should be able to get all the
>>rows, and the same number of them, as you go doing rs.next().
>
>
> The example is supposed to show that you get different behaviour with
> different values. The latency on the first call with be lower (with
> large result sets) than the latency on the second call.
>

I see, the person running it is supposed to notice a small delay between
the 50th and the 51st "a row was returned.", right?

Maybe you can make it more obvious.  You can number the lines printed
and add a comment saying that small delays _may_ be noticed every 50 lines.

Also, to make the example more realistic you could add some time
measurement for the two blocks (with and without setting the fetch size)
and suggest that the programmer play with the fetch size to find out
what is the best setting for his application needs.

Thanks for the clarifications.

Best regards,
Fernando

--
Fernando Nasser
Red Hat Canada Ltd.                     E-Mail:  fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario   M4P 2C9