Java Reference
In-Depth Information
System.out.println("cursor moved to row "+rowSet.getRow());
}catch(Exception e){
}
}
}
One of the neatest features of
RowSets
is that, in addition to using them like
ResultSets
, as
discussed in this section, you can also use them as data containers disconnected from the database.
The use of disconnected
RowSets
is discussed in the
next section
.
Disconnected RowSets
As mentioned at the beginning of this chapter, there are two main types of
RowSets
: connected and
disconnected. Connected
RowSets
maintain a connection for as long as the
RowSet
is in use.
Disconnected
RowSets
get a connection to a data source as needed.
Sun released a number of
RowSet
implementations as an early access release. These implementations
include the following:
CachedRowSet
JdbcRowSet
WebRowSet
The
CachedRowSet
is a disconnected
RowSet
, intended for use as a means of caching a
ResultSet
object's rows in memory, so it doesn't require the continuous use of a database connection. All
CachedRowSets
are scrollable and updatable, and, just like any other JavaBean, they can be
serialized. This provides a means of serializing
ResultSets
and sending them to remote clients to be
updated and sent back to the server.
Being disconnected means that a
CachedRowSet
connects to its data source only while it is reading
data to load rows and while it is sending changes back to its underlying database. The rest of the time, it
is disconnected, even while changes are being made to it. In effect, a
CachedRowSet
object can be
thought of as simply a disconnected set of rows cached in a JavaBean.
Being thin and serializable, a
CachedRowSet
can easily be sent across a wire, and it is well suited to
sending data to a thin client, such as a PDA, because, while a
CachedRowSet
object is disconnected,
it can be much leaner than a
ResultSet
object with the same data. The
CachedRowSet
class
provides a means of working with the rows of a ResultSet without the overhead associated with using
the full JDBC API.
Updating a
CachedRowSet
object is similar to updating a
JDBCRowSet
, but because the rowset is not
connected to its data source while it is being updated, one extra step is required to make a change in
the underlying data source. After calling the method
updateRow()
or
insertRow()
, a
CachedRowSet
object must also call the method
acceptChanges()
in order to make a connection
and write the updates to the data source.
The Sun implementation of the
CachedRowSet
also requires that you specifically set the name of the
table you are working with. If you fail to do this, any attempts to update the table will throw a SQL
exception.
Note
After making changes to a
CachedRowSet
using
updateRow()
or
insertRow()
, you
must also call
acceptChanges()
to make a connection and write the updates to the
data source. When you are changing or inserting several rows, you need only call
acceptChanges()
once after all calls to
updateRow()
and
insertRow()
have been
made.
Using a CachedRowSet with a PDA
