FWD » Core Development » Database

At the moment, this task is somewhat speculative, in that I'm not sure how well we are amortizing the cost of setting up PreparedStatement objects and session-related caches that we use. This will require that we figure out some way to measure this.

My suspicion is that we are taking the performance hit of preparing SQL statements rather aggressively, but maybe only using them once or a handful of times, when perhaps they could be cached and used again without again paying the cost of parsing and preparing the query statement. Likewise, we maintain a cache of Hibernate Query objects in the Persistence$Context object, which probably is cleared more often than I would like. Internally, the Hibernate session maintains a cache of HQL query plans, which I believe are used to avoid the cost of HQL->SQL parsing/transformation.

We close the Hibernate session (for non-temp-table databases) after every transaction ends, and open a new one on demand as needed for the next unit of database work. While we do maintain the current session in the context-local Persistence$Context object during the life of the transaction, applications can execute a large number of transactions in a short span of time, and any work we've done to prepare SQL statements or generate SQL from HQL is lost at each transaction boundary.

When we open a new session, we walk all of the open record buffers, determine which ones are active, and associate any DMO stored within one of them to the new session. There is some cost to this, though it has not made a strong impression in any profiling I've done recently. This effort would be eliminated if we did not close the old session, since these DMOs already would be associated with that session.

To test this theory, I speculatively stopped closing the session after each transaction was committed (without error) for a test recently. I was surprised to find that the test took noticeably longer to execute, and as a side effect of this change actually executed around 50% more database transactions. This didn't seem right, I must have overlooked something in my implementation. Further investigation is warranted -- I think there's something we can get back here.