natural progression…

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…

This entry was posted in Technical stuff. Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.