We recently moved from the poor session-per-sql-statement approach to Hibernate to the open session in view approach, complete with thread local handling of the session. (Yes, I know I could use Spring.) We do have some large, legacy import jobs that we have been migrating, and they were opening the session at the beginning, importing 40,000 records, and closing the session. At least we were trying.
As best I can figure it, Hibernate’s session cache isn’t limited in size or objects (at least by default). So the import would start strong, slow down, slow to a crawl, and then pretty much kill the server, requiring a reboot (of RedHat). So by never closing the session, we were causing the session cache to grow to occupy most of the system’s memory.
Since the cache really wasn’t doing us any good, I decided to try closing the session after each record was processed. This changed the performance dramatically. The import went from taking days to run and crashing about 2/3rds of the way through to completing in a couple of hours. While this discovery isn’t earth-shattering, I thought that I’d put this tip out there in case someone else runs into similar problems.
For most tasks, allowing several queries worth of data to accumulate in the session cache is likely harmless and probably helpful, but be aware of its impact on large jobs.