This Hibernate configuration ostensibly should control how many objects are cached in the first level cache. The reason is easy enough to understand, we don’t want to run out of memory.
But something is confusing me. Every implementation I have seen including this website
has an explicit flush and clear. No problem, but then what’s point of the configuration property?
Note: I’m assuming here is that somehow Hibernate monitors the size of the cache and if the number of objects of a certain type grows to be larger than the cache size then synchronize the cache with the db. Don’t know if that assumption is wrong ???
This configuration option has nothing to do with the size of the first-level cache. And flushing the session doesn’t remove anything from the cache. It writes the pending changes (inserts, deletes, updates) to the database. The cache is only cleared when clear() is explicitely called, or when the session is closed. If you don’t clear or clause the session (or evist specific entities), the cache will keep growing and growing. Which is not a problem since it’s typically very short-lived (the duration of a transaction).
JDBC batch updates allow sending multiple update queries in a single batch to the database. It reduces the number of network calls. You can view it as uploading an uncompressed zip containing 20 files instead of sending 20 files individually.
The confusion comes from the fact that the batch updates mentioned in the page linked in your question have nothing to do with JDBC batch updates. What Hibernate means with batch updates is “updates done by a batch job”. A batch job typically have much longer transactions that typical business use-cases, and updates hundreds, thousands or even more entities in a single transaction. This is why Hibernate recommends regularly flushing and clearing the session in this case, to avoid running out of memory.