Hibernate different types of caching : first level cache (at Session Level) & two level caching (at SessionFactory Level) & query cache.
The first-level cache is the first place that Hibernate checks for cached data. It is built in and active by default to reduce the number of SQL queries directly to the database. The first level cache can give you old values if someone else outside the current session has updated the value in database.
SessionFactory sessionFactory = HibernateUtil.getSessionFactory();
Session session = sessionFactory.getCurrentSession();
Transaction tx = session.beginTransaction();
//Get employee with id=1
Employee emp = (Employee) session.load(Employee.class, new Long(1));
printData(emp,1);
//waiting for sometime to change the data in backend
Thread.sleep(10000);
//Fetch same data again, check logs that no query fired
Employee emp1 = (Employee) session.load(Employee.class, new Long(1));
printData(emp1,2);
If the requested query results are not in the first-level cache, then the query is run against the underlying database (that is, if there is no second-level cache enabled). This cache only works at a session level, meaning each session object caches data independently, so there is no sharing of cached data across sessions, and the cached data is deleted when the session closes. This makes the cache only useful for repeated queries in the same session.
For repeated queries across multiple sessions, that’s where the second-level cache comes into play. With the Hibernate second-level cache, you can plug in a caching technology to complement the first-level cache. If the requested query results are not in the first-level cache, then the second-level cache is checked. The second-level cache shares cached data across sessions, so all sessions/users can benefit from the cached data, even for data that was inserted by another session, and even if the session that inserted the data into the second-level cache closes.
When an object is pass to save(), update(), or saveOrUpdate()method and retrieved by load(), get(), list(), iterate(), or scroll()method, that object is added to the internal cache of the Session and when the flush() is subsequently called, the state of the object is synchronised with the database.
A second-level cache improves application performance with regard to persistence for all sessions created with the same session factory. With a second-level cache, a request for an object can be served by the cache, even if the request is executed from multiple sessions, with much lower latency than if the request went to the database. Considering that ORM queries can be complex, and therefore relatively slow, a system can greatly benefit from a second-level cache to reduce the repetition of the same complex/slow queries to the underlying database.
This is especially useful for high-volume web applications that have high commonality across users in terms of SQL queries to the database. And with highly scalable caches, you can cache more data and realize more performance acceleration.
The second-level cache can be configured to use various cache providers (such as Ehcache, Infinispan, Hazelcast) with different eviction policies, time-to-live settings, and other configuration options. The duration for which an object is kept in the second-level cache is determined by the cache provider's settings.