- Use the second level cache for largely read only data. There was a table that had slipped through the cracks of our investigation that will rarely be updated. A couple of configuration entries later and it will be stored in a second level cache and refreshed on a weekly basis instead of causing an extra query hundreds or thousands of times per day.
- Eagerly fetch associations that are needed every time the transaction is called. The Criteria API in Hibernate allows the user to specify the fetch mode for every association, effectively overriding the default behavior provided by the mapping file. Setting the fetch mode to Eager for this association resulted in an extra left outer join, but it eliminated an extra query per result row.
- Don't haphazardly access collections that are not needed by all of your clients. The transaction in it's previous state would call off to a dependent collection and call the size() method on it to determine how many child records were linked to the parent. This caused every child record in that collection to be loaded by Hibernate, even though very few of the clients actually needed to know the size of this collection. Adding a property to the incoming request to determine if the transaction actually needed to fetch that count and then doing it by simply executing a separate projection based query resulted in much speedier performance for all clients.
Tuesday, November 20, 2007
I've been tasked with optimizing some slowly performing transactions in a system that has been built upon Hibernate. Yesterday I ran across an interesting situation where a single transaction was resulting in 6 separate queries to the database. This may not necessarily be bad, but when the transaction was performing as slowly as it was, we needed to take whatever means we could to speed it up. What was unique to me was that we eliminated all but 2 queries, and we eliminated each one in very different ways.