Kevin Riff wrote:
> Do you know very much about the CachedRowSet implementation? I'm trying to figure
> out how it creates an updateable result set when the underlying database doesn't
> support that feature. What technique does it use?
>
I assume we are talking about Sun's early access implementation, right?
I only know what I've read, and gleaned from looking at the examples, but doing what
CachedRowSet (CRS) does is not terribly difficult -- just tedious to implement, so
I'm glad someone else did it :-).
The key thing to recognize is that CRS operates in a *disconnected* mode most of the
time. Consider the two primary method calls used to populate the data contents:
public void populate(java.sql.ResultSet data) throws SQLException
Copies the contents of the ResultSet argument into the internal data
structures.
After this completes, you can (and should) close the passed ResultSet and its
corresponding Statement.
public void execute(java.sql.Connection conn) throws SQLException
Uses the SQL "SELECT" statement you have specified with setCommand()
to construct a Statement, open a ResultSet, call populate() on it, close the
ResultSet, and close the Statement.
In no case does the underlying ResultSet need to support updates, or even stay open.
If you are using a connection pool, you can give back the connection as soon as
you've populated the data -- you won't need a Connection again at all unless you are
supporting updating of the underlying database; at which time you will again
temporarily provide a Connection for the CachedResultSet to use:
public void acceptChanges(java.sql.Connection conn) throws SQLException;
The rest of the logic is probably devoted to keeping track of which columns and rows
have been modified, so that acceptChanges() can synthesize the required DELETE,
INSERT, and UPDATE statements. No ResultSet is used at this point in time.
Note that CRS implements Serializable, so you can do some interesting things like
pass it back and forth to an applet that does not have a JDBC connection to the
database itself. It can use your servlet as "middleware" to perform database queries
and updates indirectly.
Note also that, as the name implies (***Cached***RowSet), this particular
implementation stores all of its data in memory. It is not going to be appropriate
for the "thousands of rows returned" scenario, unless you also implement other
techniques to reduce the number of rows selected by any one query. I would not be
surprised at all to see the various database vendors implement smarter variations on
this theme as they build drivers compatible with the JDBC 2.0 standard and extension
APIs.
Craig McClanahan
===========================================================================
To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST".
FAQs on JSP can be found at:
http://java.sun.com/products/jsp/faq.html
http://www.esperanto.org.nz/jsp/jspfaq.html
