ResultSet processed at the DB server or App Server???

Question

Well,
If I have a ResultSet object that is fetched with a couple of records, where does the actual records stay???
Are these records fetched into your App server, or they still are with your DB?? So, when I call "rs.next()", evidently does the App server need to fetch each and every record from the DB, if the latter is true??? If the former is true, how do you explain that the ResultSets and other related objects are scarce DB resources???
Thx for your time.
fun_one

Answer 1

A ResultSet is a Java object, so it resides on the application server. A ResultSet is associated with a database cursor, which resides on the database server.
When you open a cursor, i.e. execute a query, the database figures out which rows match the query. The database servers builds a data structure of some sort in its memory, containing the selected data. The data structure is...cough...don't ask me, I don't know. Must be fairly significant to allow for transaction isolation, sorting, joins, ... If you just do "select * from foo" without a "where" clause, the db server may get by with a simpler data structure.
The database then sends the first, say, 10 rows to the application server. The db server also says, "here's the data on the newly opened cursor, and let's call this cursor #22."
After the application server has looped 10 times in while(res.next()), res.next() says to the db server, "dude, I have this cursor, #22, send me more data on it." The db server sends the next batch of 10 rows. This repeats until all rows are processed, or you close the ResultSet (aka close the cursor).
Closing the ResultSet tells the database server that it can release the data structure that holds the stuff in the cursor. If you don't close the cursor, the data structure needs to stay there, reserving memory, in case you rewind it and start reading it over.
So, a ResultSet + cursor take space on both the application server and at the db server.
The number of rows that are fetched at a time can be adjusted; see setFetchSize(). It's a tradeoff between the number of times a round trip has to be made, vs. the memory it takes to keep the 10 or whatever rows in memory before res.next() gets to them.
All of this depends on how the db server and the JDBC driver are implemented, but I'd guess the above is a pretty typical way of doing it.