Search Pagination Design (Server side pagination using Hibernate)

One of the biggest problem which is commonly faced in searches is pagination; On the first day of my new job, I was asked to looked the performance issues related in the search functionality of the application. When I looked at the application, application is slow when the users gets a search results of magnitude of 6000 records( each record had 10 fields to be displayed) and all the results were displayed in a single HTML page (Even if you had designed one search implementation, you would have guessed what the problem is).

There is no pagination concept implemented for this search/ problem, its a logical thing to say this search program is using whole lots of memory and slow. Assuming the search queries are already fine-tuned, Slowness can be mainly attributed to the HTML rendering by the browser. IE browser render the complete HTML and then displays it to the user so the slowness can be easily be found compared to Firefox 2, where the browser starts displaying the data as it receives (rather completely render it and displays it).

Given this background, Now we started seriously looking at pagination as the only option. In pagination, could think three approaches as a potential solutions

Lets go in details of each one of them.

Real time pagination on the server side :

This is an approach where from the UI, always pass the search criteria plus the page start record and the end record (or size of the page). So your server implementation will have these two extra arguments along with your query and returns you only the required result set which needs to be passed to front end.

On the implementation front, you could handle this scenario at two levels

Query q = s.createQuery( “your query….” );
q.setMaxResults(PAGE_SIZE);
q.setFirstResult(PAGE_SIZE * pageNumber);
List page = q.list();

Lets looks at the pros and cons of this approach

Criteria Caching based pagination on Server side

This is an approach where all records matching to the search criteria will be fetched from the database to the the server and cached. Caching is based the search criteria and a timeout period.

From the UI point of view, request will contain the search criteria plus the start record and the size( r the end record) to be fetched.

Lets looks at the pros and cons of this approach

Pagination on the UI front

This is an approach where all the records corresponding the search criteria will be retrieved from the database and held in the controller of the UI Framework and using custom tag libraries the records could be displayed in the Jsp/ Servlet.

Here are some of the recommendations for writing your own custom pagination tab lib

Lets looks at the pros and cons of this approach

Written by Ravi Nallakukkala on March 30th, 2007 with 2 comments.
Read more articles on Design and Hibernate.

Related articles

2 comments

Read the comments left by other users below, or:

Get your own gravatar by visiting gravatar.com Gaurav Bahl
#1. June 13th, 2007, at 6:35 AM.

Hi,
I couldn’t understand the diffrence between Criteria Caching based pagination on Server side and Pagination on the UI front. If we are using session variable to save the result then both are at server side only. Or are you talking about caching in database buffer.

Currently i am in the same situation, but i don’t want to increase the memory footprint at my weblogic server but want to provide pagination for my results. Can you tell me the way for that and please send me some details of that.

Gaurav

Get your own gravatar by visiting gravatar.com Ravi Nallakukkala
#2. June 13th, 2007, at 7:36 AM.

Hi Gaurav,

Answer for the first part of the question is dependent on your deployment structure. Lets take a simple example say you have 1 server instance(X) running with your server sider code (EAR containing EJB, Dao, utils) and M server instances with GUI code(War); Say EAR and War’s are deployed in different machines and M GUI instance talk to the same server side deployed code.

Now in the Criteria Caching based pagination on Server side, This server side code deployed instance (X) would hold all the (unique) criteria and its results on the server instance, where as in the Pagination on UI front approach, as the caching happens at UI front so each UI server instance will hold the search results.

Towards your second question, slightly not clear with your question, you said you wanna to provide pagination and not to increase the memory on weblogic (no mention of any caching) sounds to me like “Real time pagination on the server side” approach; which is the first approach we discussed in the article.

Say without caching if you wish to increase the page load time, may be you could consider using AJAX XML data for displaying the results and using real time pagination approach retrieve the page results and (re)populate the XML data. this way you could avoid the JSP page load time, which is quite significant in most the cases.

Did it answer your second question?

Remember the thumb rule “Sacrifice memory for time and vice-versa” :-)

Thanks,
Ravi

Leave your comment...

If you want to leave your comment on this article, simply fill out the next form:




You can use these XHTML tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <code> <em> <i> <strike> <strong> .