Re: JDBC stored procs doc patch

Fernando Nasser <fnasser(at)redhat(dot)com> writes:

> > +
> > + <para>Changing code to cursor mode is as simple as setting the
> > + fetch size of the <classname>Statement</classname> to the
> > + appropriate size. Setting the fecth size back to 0 will cause
> > + all rows to be cached (the default behaviour).
> > +
>
> Perhaps you should mention the retrieval all rows must happen inside a
> transaction. The cursor that is created is not HOLD or anything.

Ok. I'll do that.

> > +<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.

Nic