OK, for the most part, if your application (commercial or otherwise) has a small, let’s say trivial amount of data. Simply retrieving as few hundred records and displaying them shouldn’t be too IO intensive. but with natural progression, some trivial applications become non-trivial, and require a bit more care.
In my case, I retrieve some records via Hibernate. Then I display results via DisplayTag, and I wasn’t using partial-lists. Some of you might be thinking, “Hey genius, of course it’s going to be slow!” Well, you’re right: there’s a ton of object creation going on behind the scenes, and asking DisplayTag to decorate and sort n-thousand records is not going to work. With my non-trivial test data, I saw responses go from sub-second to ~5 seconds! So, with DisplayTag’s advice, I turned my attention to PaginatedLists. Nothing too crazy, basic ValueList Handler. I give PaginatedList instances a Spring-wired Dao, a SearchBean (search params) and an optional PagingAndSortingInfo reference. As you may have guessed, PagingAndSortingInfo knows the following:
- what column(s) are being sorted,
- in what direction,
- what page sizes are,
- and lastly, what page we are on.
As expected, performance goes back to sub-second. However, there’s a catch: I externalize all my queries (both big and small); regardess of what PagingAndSortingInfo may know, I can’t apply sorting information to an existing Hibernate Query. Since the returned is not a Hibernate Collection, Session.filter(…) is also out of the question. Lucky for me, there’s Hibernate Search. Hope it’s not too much work. I’ll let you know how it goes…