Hibernate session Cache

Session Overview

The Session interface is the most basic interface that Hibernate provides to the application to manipulate the database, providing basic methods for saving, updating, deleting, and loading Java objects.

The Session has a cache, and the object in the cache is called the persisted object, which corresponds to the related record in the database. The Session can synchronize the update of the database by running the associated SQL statement at some point in time, in accordance with the changes in the object in the cache, which is known as flush cache (flush)

Standing in the perspective of persistence, Hibernate divides objects into 4 states: persistent state, temporary state, Free State, delete state. The specific method of the Session allows the object to transition from one state to another state.

Session Cache

A series of Java collections are included in the implementation of the session interface, which forms the session cache. Only the Session instance does not have an end-of-life cycle, and the cache is not cleaned. The object stored in its cache will not end the life cycle

Session caching reduces the frequency of Hibernate application access to the database.

Operation Session Cache

Flush ()

Flush: Keeps the records in the database tables consistent with the state of the objects in the session cache. In order to remain consistent. The appropriate SQL statement may be sent.

by default, the Session refreshes the cache at the following point in time:

Explicitly invoking the flush () method of the Session may send the SQL statement (why it is used, because the query does not send a SQL update because the state in the database matches the state of the current object), but does not commit the transaction (the SQL statement is sent.) A transaction must be committed before the database is updated)

When the application calls Transaction's commit () method, the method first flush (update) and then commits the transaction to the database

When an application runs some query (HQL, Criteria) operation, it is assumed that the properties of persisted objects in the cache have changed. The cache is flush first. To ensure that the results of the query reflect the latest state of the persisted object (this, of course, is only updated within the scope of the transaction and not synchronized to the database.) Only commit transactions will be updated to the database)

exception to flush cache: Assuming that the object uses the native generator to generate the OID (the record ID is generated by the underlying database using the self-increment), the INSERT statement that inserts the entity into the database is run immediately when the Save () method of the Session is called Synchronize to the database. The ID must be guaranteed to exist because of the Save method. (assuming that the ID is generated by hibernate, the insert synchronization to the database is sent only when the commit transaction is committed)the difference between the commit () and flush () methods: Flush runs a series of SQL statements, but does not commit the transaction; The commit method calls the flush () method before committing the transaction. Means committing a transaction means permanently saving the database operation.

set the point in time to refresh the cache (learn about it.) Usually do not change)

If you want to change the default time point of Flush, you can explicitly set the time point of flush by the Setflushmode () method of the Session

Refresh ()

Forces a SELECT statement to be sent so that the state of the object in the session cache is consistent with the corresponding record in the database table. Controlled by the database isolation level.

(You must understand the database isolation level, as seen below)

isolation level of the database

For multiple transactions executed at the same time, when these transactions access the same data in the database, it is assumed that the necessary isolation mechanisms are not taken, resulting in various concurrency problems:

Dirty reads: For two things T1, T2, T1 read the fields that have been T2 updated but have not yet been committed. Then, if T2 rolls back, the content read by T1 is temporary and invalid.

Do not reread: for two things T1, T2, T1 read a field, and T2 updated the field. After that, T1 reads the same field again, and the value is different.

Phantom reading: For two things T1, T2, T1 reads a field from a table, and then T2 inserts some new rows into the table. Then, assuming that T1 reads the same table again, it will have a few more rows.

Database transaction Isolation: The database system must have the ability to isolate concurrent execution of individual transactions so that they do not affect each other and avoid various concurrency problems.

The degree to which a transaction is isolated from other transactions is called the isolation level. The database specifies a variety of transaction isolation levels, with different isolation levels corresponding to the degree of interference, the higher the isolation level, the better the consistency of data, but the weaker the concurrency
4 transaction isolation levels provided by the database:

2 Kinds of transaction isolation levels supported by Oracle: READ commited, SERIALIZABLE. The default transaction isolation level for Oracle is:READ commited

Mysql supports the transaction isolation level in 4. The default transaction isolation level for Mysql is: Repeatable READ
Setting the isolation level in MYSQL

• A separate database connection is obtained for each MySQL program that is started. Each database connection has a global variable @ @tx_isolation that represents the current transaction isolation level. MySQL default Isolation level is repeatable Read
• To view the current isolation level: SELECT @ @tx_isolation;
  
• To set the isolation level for the current MySQL connection:
  Set TRANSACTION ISOLATION level Read Committed;
  
• Set the global isolation level of the database system:
  Set global transaction Isolation level Read Committed;
  

Setting the isolation level in Hibernate

• The JDBC database connection uses the default isolation level of the database system. The isolation level can be set explicitly in Hibernate's configuration file. Each isolation level corresponds to an integer: –1.read uncommited–2.read commited–4. Repeatable read–8.serializeable
• Hibernate sets the isolation level of a transaction by specifying the Hibernate.connection.isolation property for the Hibernate mapping file
  

Clear () clean up the cache

Hibernate session Cache