January 16, 2021
Hot Topics:

A Pagination Technique Using Spring

  • By Vlad Kofman
  • Send Email »
  • More Articles »

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 questions—which will drive the design logic—during 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, 10–5000 per query), you can implement server-side (or even client-side) solutions. If your result set is static but it can exceed 1000–2000 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 the client-side implantation, you transfer the entire result set from the database to the application server and then to the client. The client then shows only a portion of the results to eliminate user scrolling or to fit them into the display area. This mechanism requires no special logic on the database or application server layers. Rather, it implements pagination logic on the client using specific client technology, such as Flex, JavaScript, Applets, and so on. (For a complete example of one client-side implementation, see my other article "Implementing Search Result Pagination in a Web Application".)

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.

Page 1 of 3

This article was originally published on July 21, 2009

Enterprise Development Update

Don't miss an article. Subscribe to our newsletter below.

Thanks for your registration, follow us on our social networks to keep up-to-date