Thread: JDBC best practice

I'm using a Postgres table as the data source for a JTable
in a Java app.  As a first approximation, I'm implementing
AbstractTableModel.getValueAt() like so:

    public Object getValueAt(int row, int col)
    {
        try
        {
            rs_.absolute(row + 1);
            return rs_.getObject(col + 1);
        }
        catch (Exception e)
        {
            ...
        }
        return null;
    }

Where rs_ is a RecordSet object.  What I'm wondering is
whether it's better to call absolute() or relative() or
next()/previous().  If absolute() is the slowest call,
then I can cache the last row fetched and move relative
to that.

My suspicion is that next()/previous() is much faster
than absolute() when the record to be fetched is very near
the last record fetched.  I haven't actually tried it, but
I'd like some insight if others can already answer this
question based on knowledge of the server side and/or the
JDBC driver.

__
David B. Held
Software Engineer/Array Services Group
200 14th Ave. East,  Sartell, MN 56377
320.534.3637 320.253.7800 800.752.8129

On Mon, 28 Mar 2005, Dave Held wrote:

> I'm using a Postgres table as the data source for a JTable in a Java
> app.  Where rs_ is a RecordSet object.  What I'm wondering is whether
> it's better to call absolute() or relative() or next()/previous().  If
> absolute() is the slowest call, then I can cache the last row fetched
> and move relative to that.
>
> My suspicion is that next()/previous() is much faster than absolute()
> when the record to be fetched is very near the last record fetched.  I
> haven't actually tried it, but I'd like some insight if others can
> already answer this question based on knowledge of the server side
> and/or the JDBC driver.

There are two types of ResultSets that can be returned by the JDBC driver.
One is backed by a cursor and can only be used for TYPE_FORWARD_ONLY
ResultSets so it is not really applicable to you.  The other method
retrieves all results at once and stashes them in a Vector.  This makes
next, absolute, and relative positioning all equal cost.

Kris Jurka