Summary of level 1 cache, level 2 cache, and query cache in hibernate

I,Level 1 Cache 1. The first-level cache only caches the entire object and does not cache object attributes; 2. The first-level cache is a session-level cache and cannot be used across multiple session objects; 3. The load/get method of the session supports reading and writing of the first-level cache; 4. The list interface of query only supports writing in the first-level cache, and objects cannot be read from the first-level cache. The list interface sends an SQL statement to load objects; 5. The iterate interface of query supports writing in the first-level cache and reading objects from the first-level cache (if any ). Each time you use the iterate interface to query an object, you must first load the ID list of the query object in SQL. If an object needs to be used, it is queried from the first-level cache based on the Object ID. If yes, It is loaded directly. If no, an SQL statement is sent to load data from the database (1 + N problem occurs ). 6. The session save method puts the saved object in the first-level cache. Therefore, if you want to save a large number of objects, you should clear the first-level cache in time. You can use the clear () method of the session. 7. The first-level cache is used by default by Hibernate and can be used without configuration.   II,Level 2 Cache 1. The second-level cache can only cache the entire object and cannot cache object attributes. The usage of the load/get method and list/iterate method is the same as that of the first-level cache. 2. Unlike the level-1 cache, the level-2 cache is a sessionfactory-level cache that allows multiple session objects to be shared. 3. Some preparation steps must be performed before using the second-level cache (take ehcache as an example ): (1) the xml configuration file that requires ehcache (Set "Maximum number of cache objects", "whether objects are invalid", "idle time allowed by objects", "Object survival time", and "Whether to cache to disk when the number of objects exceeds the limit "); (2) Enable Level 2 cache in the configuration file hibernate. cfg. XML (enable by default, no need to display the configuration ): <Property name ="Hibernate. cache. use_second_level_cache"> True </property> (3) supplier of the specified level-2 Cache: <Property name ="Hibernate. cache. provider_class"> Org. hibernate. cache. ehcacheprovider </property> (4) Specify the class to be cached and the cache method (which can be configured in hibernate. cfg. xml or. HBM. xml of the corresponding class ): Configure in hibernate. cfg. xml: <Class-Cache Usage ="Read-only"Class ="My. Student"/> Configure in student. HBM. XML (must be completed before the configuration ID ): <Cache Usage ="Read-only"/> (5) You can dynamically set whether to allow read and write to the second-level cache through session. The methods are session. setcachemode (cachemode. Get) and session. setcachemode (cachemode. Put) (6) The evit () of sessionfactory caches an object level-2.   III,Query Cache The query cache is designed for the query list method. For the iterate () method, whether it is to query the object attributes or the object itself, there is no difference between the query cache and the no-use! 1.Query attributes using the cache: (1) The query cache must be enabled in hibernate. cfg. xml: <Property name ="Hibernate. cache. use_query_cache"> True </property> (2) If you want to use the query cache (write or read cache) in the code, you can enable it by using the setcacheable (true) method of the query; (3) the lifecycle of the query cache is irrelevant to the session (cross-session queries can be performed). When the table associated with the query changes, the query cache lifecycle ends (delete, update, and modify) (4) When the query cache is enabled and the query object attributes (one or more attributes can be used) are used, the query list method can be used to write the obtained attribute set to the query cache. If the query cache already has the attributes of this object, it will not issue an SQL statement and be obtained directly from the query cache; 2.Query objects in the cache: (5) If the query cache is enabled and the object is queried through the list interface, an SQL statement is sent to obtain the object from the database during the first query, and the Object ID list is placed in the query cache; if you query an object in the cache again, an SQL statement is sent based on the Object ID to load the object from the database (n SQL statements are then issued) (6) If both query and second-level cache are enabled, n SQL statements will not be issued in (5), but will be directly loaded from the second-level cache. (Now the list interface has the ability to read the second-level cache !!!)