Re: streaming result sets: progress

On Friday 22 November 2002 03:15 pm, Nic Ferrier wrote:
> Whoa! big time over run... anyway, getting back to this:
>
> Scott Lamb <slamb(at)slamb(dot)org> writes:
> > Nic Ferrier wrote:
> > > Thomas O'Dowd writes:
> > > >>3) I think the transaction characteristics of the current patch are
> > > >> just fine and conform to the jdbc specification. The code should
> > > >> automatically close the resultset when a commit occurs. One thing
> > > >> that will be confusing is that noncursor based result sets will work
> > > >> accross commits, but cursor based ones won't. But I think that is
> > > >> reasonable.
> > > >
> > > >Sounds reasonable to me as long as its clear to the programmer what
> > > > type they are using. I definitely don't want to see the noncursor
> > > > based resultsets closed, but I can't see a better solution for cursor
> > > > based ones...
> > >
> > > How can we make clear what type of ResultSet is being used?
> >
> > I suggest with ResultSet.CLOSE_CURSORS_AT_COMMIT (cursor method) vs
> > ResultSet.HOLD_CURSORS_OVER_COMMIT (old method). You can both request a
> > certain type when you create a Statement or PreparedStatement and get
> > the type of the resultset from the Statement or PreparedStatement.
>
> So what you're saying is that this code:
>
> Statement st
> = connection.createStatement(ResultSet.CLOSE_CURSORS_AT_COMMIT,
> ResulSet.CONCUR_READ_ONLY);
> ResultSet rs = st.executeQuery("select * from table");
>
>
> would produce a cursor based res set whereas:
>
> Statement st = connection.createStatement();
> ResultSet rs = st.executeQuery("select * from table");
>
> would not.
>
>
> That would mean that we didn't need the fetch size signal. Or we
> could use the fetchSize signal as well.
>
>
> Note also that CLOSE_CURSORS_AT_COMMIT is not actually a result set
> type so it _might_ break other code.
>
>
> Anyone else have any opinion on this?
>

I think that if fetchSize > 0 then user cursor, if fetchSize = 0 then use old way

regards
Haris Peco