Dag H. Wanvik wrote: > Hi, > > >>>>>>"Knut" == Knut Anders Hatlen <[EMAIL PROTECTED]> wrote: > > > Knut> > Knut> | Derby | DB2 univ | Postgres | MySQL > Knut> --------------------------------------------------------------------- > Knut> DriverManager.getConnection | X | X | X | X > Knut> Connection.setAutoCommit(false) | | | | X > Knut> Connection.prepareStatement | X | | | X > Knut> --------------------------------------------------------------------- > Knut> PreparedStatement.executeQuery | X | X | X | X > Knut> ResultSet.next | X | X | | > Knut> ResultSet.close | X | X | | > Knut> Connection.commit | X | X | X | X > Knut> > Knut> The first three methods are not candidates for optimization, in my > Knut> opinion, since a well-written application won't call them > Knut> frequently. But I think we should do something with the last four > Knut> methods. > Knut> > Knut> My initial thought is that we should try to: > Knut> > Knut> 1) Pre-fetch rows in PreparedStatement.executeQuery(), saving one > Knut> round trip per select statement. > Knut> > Knut> 2) Delay ResultSet.close() and send it piggybacked on the next JDBC > Knut> call, saving one round trip per select statement when autocommit > Knut> is off. > > If the next JDBC communication won't take place for a while, this > second optimization can significantly delay the release of result set > locks, so I would be hesitant to recommend this optimization (as a > default behavior, anyway), since other transactions might block, > without the user realizing the cause of it.
Can we take advantage of any knowledge of how the embedded engine is closing ResultSets automatically, at least for forward only result sets? >From the 50,000 foot level it seems to me that for a forward only result set that has been exhausted (rs.next() returned false) the close on the client should not need to send any communication to the server Dan.
