A Pagination Technique Using Spring
You can implement the pagination of result sets in Java-based web applications in many ways. You can do it with custom algorithms or third-party packages, on the server side or client side, and so on. The Spring Framework provides a convenient method for server-side implementation out of the box.
This article demonstrates how to use the Spring Framework to implement a pagination mechanism for server responses. While it focuses on web applications that use Java and Spring, it will touch on related pagination techniques as well.
The implementation discussed here may not be suitable for all scenarios. You have to account for considerations such as performance and the needs of the particular application during the design process. To help with design decisions, this article also provides the cons and pros of the pagination implementation.
UI and Performance Considerations
In enterprise Java web applications with n-tier design, the data flow typically goes from the database layer through the web application layer to the client layer. The processing of the business logic usually resides at the application server layer, and the client gets the end result rendered in some form of UI.
Presenting medium-sized to large data sets in tabular form usually requires a pagination mechanism that enables the client to see some portion of the final result and navigate back and forth through the result set. This is a very common feature in modern web applications.
You must answer a few very important questionswhich will drive the design logicduring pagination design. The maximum result set per query, performance requirements, and the need for real-time data all need to be determined upfront. If the application will always return small to medium-sized results (for example, 105000 per query), you can implement server-side (or even client-side) solutions. If your result set is static but it can exceed 10002000 rows, you could consider server memory caching, but only within server memory limits. If your result set is dynamic and is constantly changing in real time, then even small responses need to come directly from the database layer.
With application server pagination, the entire result set is transferred from the database to the application server, but only a portion is then transferred to the client. Specific server-side pagination logic controls (usually with caching) what is sent to the client based on the requests. Usually you use this method with third-party packages or libraries, and it is server technology specific. For example, it is supported by the Spring Framework, which this article describes.
With the database layer implementation, only a portion of the entire result set is transferred from the database to the application server, and then from the app server to the client. This method depends on a specific database vendor implementation and support of that implementation on the application server layer. For example, these implementations can include SQL syntax that can "limit" a result set, scrollable result sets (supported in some JDBC drivers), cursor-based stored procedures or functions, and so on. The database layer implementation depends on the database and can be either easy or cumbersome to implement, because each database vendor provides a different mechanism for data retrieval. But most modern ORM databases provide this functionality.
The tables in the next section can help you decide on the best approach.
Methods of Pagination: Back End, Middle Tier, and Front End
The pagination algorithm can reside on any of the n-tier application layers, but the response size ultimately determines where it can be implemented.
This table shows the pros and cons of the location of the pagination logic.