Hibernate implements a good CACHE mechanism, we can quickly improve system data reading performance with Hibernate's internal cache.
It should be noted that: Hibernate is an application-level data access layer package, which can only maintain the validity of data in cache within its scope, that is, in our system and third-party system sharing database Hibernate's Cache mechanism may fail. A simple example, if you modify the value in the library with Access, then this will not update the buffer pool in the JVM, which leads to the production of the data.
Hibernate maintains a buffer pool in the local JVM and saves the data obtained from the database to the pool for the next reuse (if the data in Hibernate has changed, Hibernate also updates the data version in the pool). At this point, if there is a third-party system changes the database, Hibernate does not know that the data in the database has changed, that is, the data in the pool is modified by the previous version, when reading, Hibernate This data will be returned to the upper layer code, resulting in potential issues. The definition of the external system is not limited to a third-party system other than the system, even in this system, if there is any other data access method bypassing the Hibernate data storage mechanism, then the validity of Cache must also be taken into consideration. For example, in the same system, the Hibernate and JDBC-based data access is computed, and Hibernate cannot know the data update when updating the database through the JDBC, resulting in the appearance of dirty data.
Java-based cache implementation, the easiest way to Hashtable, Hibernate provides HashTable Cache implementation mechanism, but due to its performance and functional limitations, only for development and commissioning. At the same time, Hibernate also provides interfaces for third-party Cache, such as JCS, EHCACHE, OSCACHE, JBOSS Cache, Swarmcache, and so on.
Cache in Hibernate is roughly divided into two layers, the first layer of cache is implemented in the session, which is transaction-level data buffer. Once the transaction ends, this cache is invalid. This layer Cache is built-in implementation without we need to interfere. The second layer cache is a management container that caches data in the scope of its instance in Hibernate.
We mainly learn the second floor cache.
Hibernate has used a child item in the Java Caching System -apache Turbine project as the default second floor cache implementation. Due to the development of JCS, the new version of Hibernate has removed JCS and uses Ehcache as its default second-level Cache implementation with EHCACHE. Relative to JCS, EHCache is more stable, and has better cache scheduling performance, and the defect is not available to distributed cache. If our system needs to deploy in multiple devices, share the same database, you must use support distribution Cache Cache implementations (such as JCS, JBossCache) to avoid cache inconsistency between different system instances, causing dirty data. Hibernate has a good package for Cache, and the transparent CACHE mechanism makes us no need to face cumbersome Cache maintenance details in the implementation of the upper structure.
The Cache implementation supported by Hibernate is:
Hashtable: net.sf.hibERNATE.CACHE.HASHTABLECACHEPROVIDER Supports query buffer.
Ehcache: Net.sf.ehcache.hibider.Provider supports query buffer.
Oscache: Net.sf.hibernate.cache.oscacheProvider supports query buffering.
Swarmcache: Net.sf.hibernate.cache.swarmcacheProvider supports cluster.
JBOSSCACHE: Net.sf.hibernate.cache.treecacheProvider supports cluster.
Swarmcache provides a distributed cache of the Invalidation mode, that is, when a node in the cluster updates the data in the cache, that is, the other nodes in the cluster will abolish this data, after each node needs to use this data, Will re-read and populate them into the cache. JBOSSCache provides a REAPPLICATION buffer, that is, if the data of a node in the cluster changes, the node copies the latest version of the changed data to each node in the cluster to maintain all node status.
Using the second layer of cache, you need to configure (omit) in Hibernate configuration files, mainly introducing Cache policies.
The optional value of the Cache policy has the following:
1. Read-Only is read-only. 2. Read-Write can be readable. 3. Nonstrict-read-write If the program is not very strict on concurrent data modification, only occasionally need to update the data, you can use this option to reduce an unsatisfactory check to achieve better performance. 4. Transactional transactional cache. In transactional cache, Cache's related operations are also added to the transaction, and if the transaction fails for some reason, we can roll back to the status before the data in the buffer pool. In the current Hibernate built-in cache, only JBossCache supports transactional Cache implementation.
Other parameters Description:
MaxElementSINMEMORY = "10000" // Cache Maximum allowable saved data number Eternal = "false" // Cache data is constant TIMETOIDLESECONDS = "120" // Cache data passivation time TimeEtoliversityConds = "120" // cache data Whether the disk cache is enabled when the survival time OVERFLOWTODISK = "True" //
It is necessary to pay attention to the Hibernate database query mechanism. When we take the data from the query results, we use the most two methods: query.list (); query.Iterage ();
For a List method, it is actually the Hibernate gets all records through a SELECT SQL. And read it, fill in the POJO.
The iTerate method is first, first obtains the ID of all records that meet the query criteria, and then loop operation on this ID collection, and remove the records corresponding to each ID, then fill in Pojo Back .
That is, for the List operation, a SQL is required to be completed. For the Iteerate operation, N 1 SQL is required. It seems to be a bit redundant, but there is still its unique effect in different situations, such as inquiring massive data, if the result set will be removed at a time, the overhead of the memory may not be able to withstand. On the other hand, for our current Cache mechanism, the List method will not read data from the Cache, which is always one-time recording that eligible from the database. The Iteerate method is based on the ID, and this implementation mechanism is also possible to read data from cache. Hibernate first looks for the corresponding data in local cache according to this ID, if not found, then in the database Retrieve.
Information: Hibernate Development Guide
