No, this is misleading. You're probably not waiting for "Java processing" here; you're really waiting for (a) the DB, and (b) the network. Just because a ResultSet object has been returned, that does
not mean that all the data has been received from the DB. (Even though it might look that way.) Instead, a ResultSet is typically still associated with the Connection and Statement that created it, in such a way that the ResultSet is still busy getting data from the DB when you start using it. This allows you to start using the ResultSet and processing results as soon as any rows of data are available, rather than waiting until
all the rows have been sent. It's a form of multitasking. But if you Java-based processing is simple, then the JVM can keep up with data rows as they're sent across the network. Which means that every time you call rs.next(), you're probably waiting for the DB to send more data.
Jeanne has given good pertinent advice here. Chances are, you don't want to try to display all 7200 records on the page at one anyway, right? You want to gather maybe 20-50 records at once and make a page that shows them, right away, rather than waiting for the remaining 7150 records to be sent. No matter what you do, it would take time to find and send 7200 records, and you don't need to wait that long to generate one page.
Offhand, I would probably have one
thread which processes the ResultSet and adds received data to a List. Then another thread generates a page by looking at the List to select the appropriate rows. For the first page request, you might need rows 1-50. Maybe only 20 rows are available the first time you check. So you rocess the rows that are available, then wait for more. Once row 50 has arrived, the page-formatting thread can finish a page and send it off. Meanwhile the RS-processing thread just keeps on processing results as they come in. Of course you need to synchonize access to the shared mutable List here; that's normal.