Cache and Crud for hibernate

The

 hibernate as a lightweight ORM framework that is now more prevalent, has been popular in the country since 2003 and is now dominant in the persistence layer. Although the rich and flexible hql and the object of the criteria query, the programmer from the complex and cumbersome JDBC freed, but as a framework for the persistence layer, its performance is the most important core issue. And the core of performance is the cache, due to the recent study of these, so I learned something to share with you, hoping to play a good effect.
   before saying this, let's talk about three states of Hibernate entity objects:
   1.Transient: The so-called Transient that entity objects exist in memory, regardless of the records in the database. The
   2.persient:persient object corresponds to a record in the database, and it can be understood that if an entity object is associated with a session and is in the validity period of the corresponding session, Then it's in a persient state.
   3.Detached: The so-called Detached is the state of the Persient object corresponding to the session after the session is closed.
     What we normally refer to as PO (persistent object) is the object in the Persient state, and VO (Value object) refers to the transient and detached states.
     start with crud
   Save: A lot of ways to save in hibernate I'm basically talking about a few of the following
         1.save () method, when you call the Save method, you first look for the Save object in the session cache if the entity object is already in the Persient state, returns directly, or does not implement SQL operations. The saved entity object is added to the session cache (the Save method does not add the entity to level two cache), and the existing cascade relationship is recursively processed.
        2.saveorupdate () method: The same as the Save method, which first looks in the session cache to determine if the object is saved state, If the object is in PErsient, does not perform the operation, is in transient to perform the save operation, and is in detached call save to reconnect the object to the session.
       here to note that the batch operation should be timely to the session of the flush operation to avoid outofmenoryerror.
   Delete: Delete I mainly say bulk deletion, hibernate must first load all eligible data into memory prior to bulk deletion (this is the problem that all ORM frameworks must face. This is mainly for the current internal cache and two-level cache data collation to save and database consistency. This is the face of it. If the operation data volume is too large, also appear outofmenoryerror, so it is recommended to use iterative deletion.
   Modify: Modify the main talk about the Update method, update and the previous save like the first to do in the internal cache to find, pay attention to two points,
      The Entity object call Update for the   1.Persient state has no effect, and update SQL will be executed in the Session.flush () method.
   Query: Queries are the most affected by caching, mainly talking about the following kinds of queries
       1. Load and get: The main difference is that load is found in the level two cache, and get is not found in the internal cache and will skip level two cache directly for SQL operations. The list () and iterate () method of the
       2.createQuery (), list () cannot actually use caching, he writes to the cache, Ierate is the first to find all eligible data IDs (first in the local cache) in the execution of the corresponding select to obtain corresponding records, iterate method is best used to find the entity object in the cache already exists, otherwise query performance is low, easy to produce n+1 phenomenon.
       actually still have query cache but afraid of too long, annoying so that the pen, in fact, the cache is a very deep problem, it is worth studying.