Cache of Session

The session's cache is also known as Hibernate's first-level cache. The session cache is built-in and cannot be unloaded, and the session cache is a transaction-scoped cache (the session object's life cycle usually corresponds to a database or a transaction). The object in the session cache is a persisted object, and the session updates the database synchronously, depending on the state of the persisted object. In the first-level cache, each instance of a persisted class has a unique object identifier (OID). Normally, a first-level cache is automatically maintained by hibernate without human intervention.

Application of Session cache:

The session interface hibernate provides the application with the most important interface for manipulating the database, which provides basic methods for saving, updating, deleting, and loading.

(1) Save (), update (), and Saveorupdate (): When the session object calls the Save () method, the update () method, or the Saveorupdate () method to persist an object, The object is added to the session's cache.

(2) Get () and load (): When the session object calls the Get () method or the load () method to fetch an object from the database, the object is also added to the session cache.

(3) Close (): When the Session object calls the close () method, the session cache is emptied.

The role of the session cache:

(1) Reduce database access frequency: Applications are reading persisted objects from memory much faster than querying data in the database, so using session caching can improve database access performance.

(2) Ensure that the objects in the cache are synchronized with the data in the database: When the state of the persisted object in the cache changes, the session does not immediately execute the relevant SQL statement, which allows the session to merge several related SQL statements into one SQL statement to reduce the number of accesses to the database. Improve access efficiency.

(3) When there is a cyclic correlation between persisted objects in the cache, the session guarantees that there is no dead loop to access the object graph, and that the JVM stack overflow exception is caused by a dead loop.

In general, the session cleans up the cache at the following point in time:

(1) When the application calls transaction's commit () method, the commit () method cleans up the cache before committing the transaction to the database.

(2) When the application displays the flush () method that invokes the session.

(3) When the application calls the session's find () or itreate (), if the properties of the persisted object in the cache change, the cache is cleaned first to ensure that the results of the query reflect the latest state of the persisted object.

Cache of Session