Disclaimer: This blog post on SQL pagination & JDBC pagination is posted by me.
Disregarding Hibernate pagination, we can use SQL pagination / JDBC pagination
SQL pagination
There are two basic approaches:
- operating on piecemeal result set (New Query for Each Page)
- operating on full result set
The way to do it is SQL specific
For MySQL / many other SQLs it can be done with limit and offset
Postgresql: http://microjet.ath.cx/WebWiki/ResultPaginationWithPostgresql.html
In Oracle, it use the same form as to handle "Top-N query" e.g. who are the 5 highest paid employee, which is optimized
select * from ( select a.*, rownum rnum
from ( YOUR_QUERY_GOES_HERE -- including the order by ) a
where rownum <= MAX_ROWS )
where rnum >= MIN_ROWS
Here is a very detailed explanation on ROW-NUM
Similar SO Thread
JDBC Pagination
The question comes into mind is: when I execute the SQL, how is the result being loaded? Immediately or on request? same as this SO thread
First we need to understand some basics of JDBC, as from Oracle
Per javadoc: statement.execute()
execute: Returns true if the first object that the query returns is a ResultSet object. Use this method if the query could return one or more ResultSet objects. Retrieve the ResultSet objects returned from the query by repeatedly calling Statement.getResutSet.
We access data in Resultset via a cursor. Note this cursor is different from that of DB while it is a pointer initially positioned before the first row of data.
The data is fetch on request. while when you do the execute() you are fetching for the first time.
Then, how many data is loaded? It is configurable.
One can use the java API setFetchSize() method on ResultSet to control how many rows are fetched from DB a time by the driver, how big the blocks it retrieves at once.
For example assume the total result is 1000. If fetch size is 100, fetching the 1st row will load 100 rows from DB and 2nd to 100th row will be loaded from local memory.to query 101st row another 100 rows will be load into memory.
From JavaDoc
Gives the JDBC driver a hint as to the number of rows that should be fetched from the database when more rows are needed for ResultSet objects genrated by this Statement. If the value specified is zero, then the hint is ignored. The default value is zero.
Note the word "hint" - it can be override by driver specific implementation.
This is also what the "Limit Rows to 100" feature in client like SQL developer based on.
Completing the whole solution, to scroll results, one need to consider the ResultSet Types and ScrollableCursor in API
One can find an example implementation from this post in oracle
which is from the book Oracle Toplink Developer's Guide
Example 112 JDBC Driver Fetch Size
ReadAllQuery query = new ReadAllQuery();
query.setReferenceClass(Employee.class);
query.setSelectionCriteria(new ExpressionBuilder.get("id").greaterThan(100));
// Set the JDBC fetch size
query.setFetchSize(50);
// Configure the query to return results as a ScrollableCursor
query.useScrollableCursor();
// Execute the query
ScrollableCursor cursor = (ScrollableCursor) session.executeQuery(query);
// Iterate over the results
while (cursor.hasNext()) {
System.out.println(cursor.next().toString());
}
cursor.close();
.....................
After all, the questions boil to
Which is the better way to do pagination?
Note the SQL should be ORDER by to make sense in the SQL approach,
Otherwise it is possible to show some rows again in next page.
Below is some points from Postgresql's documentation on JDBC Driver and other SO answers
First off, the original query would need to have an ORDER BY clause in order to make the paging solution work reasonably. Otherwise, it would be perfectly valid for Oracle to return the same 500 rows for the first page, the second page, and the Nth page
The major difference is for the JDBC way, it is required to hold the connection during the fetching. This may not be suitable in stateless web application, for example.
For SQL way
the syntax is SQL specific and may not be easy to maintain.
For JDBC way
- The connection to the server must be using the V3 protocol. This is
the default for (and is only supported by) server versions 7.4 and
later.
- The Connection must not be in autocommit mode. The backend
closes cursors at the end of transactions, so in autocommit mode the
backend will have closed the cursor before anything can be fetched
from it.
- The Statement must be created with a ResultSet type of
ResultSet.TYPE_FORWARD_ONLY. This is the default, so no code will
need to be rewritten to take advantage of this, but it also means
that you cannot scroll backwards or otherwise jump around in the
ResultSet.
- The query given must be a single statement, not multiple
statements strung together with semicolons.
Some Further reading
This post is about performance tuning with optical fetch size