Hibernate first level cache - does it Sync?
Asked Answered
H

3

6

I am aware of the fact that Session is first level cache used by Hibernate, and once we retrieve an entity from the session, the subsequent get calls for the same entity with same identifier is fetched from the session instead of DB, until the session is Open.

Having said that, I have a doubt regarding how hibernate syncs the first level cache with DB? Consider the following scenario

//Lets say I have created the session

Session s1 = sessionFactory.getSession();
User u1 = s1.get(User.class, 1); //Getting User with ID=1
//s1 is not yet closed

//Lets say I create some other session

Session s2 = sessionFactory.getSession();
User u2 = s2.get(User.class, 1); //Getting User with ID=1
u2.setName("Abc"); // Changed a field
s2.save(u2); // Saved the changes to DB
s2.close(); //Closed the 2nd session

//Now when I once again retrieve User with ID=1 from s1, will I get updated User?
User u3 = s1.get(User.class, 1);// Here as per my understanding cache is used

So my question is

  • Since u3 is fetched from 1st level cache, does u3 have updated value?
  • If some one directly updates DB and modifies User object when session is open, does the session sync with DB?

Thanks in advance for your time and effort on this thread

Heffron answered 10/9, 2013 at 14:28 Comment(0)
K
3

No, Hibernate doesn't do anything to synchronize state of the entities in session cache with the DB, unless you request it explicitly.

Usually it's not a problem, because active work usually happens inside a transaction, and operations inside a transaction are not supposed to see changes made by other concurrent transactions (details depend on isolation level, though). So, behavior of Hibernate complements the typical semantics of transaction isolation in this case.

There can also be situations when state of the entity need to be explicitly synchronized to reflect changes made inside the same transaction. It may be caused by bulk update queries or execution of database triggers. In this case you need to request such a synchronization explicitly by calling refresh().

Krems answered 10/9, 2013 at 14:54 Comment(0)
S
3

You'll need to call Session.evict(Object) on s1 with u1 as an argument in order to get a fresh lookup. Alternatively, for this case, you could also call Session.clear() on s1 as well to get the same effect. You could also call Session.refresh(Object object) to just refresh the state of u1 as well.

Note that transactions can take an undefined amount of time (usually not very long though) to be seen by other clients after they are committed. The update may not be visible immediately to other sessions using different connections.

Shrug answered 10/9, 2013 at 14:50 Comment(0)
K
3

No, Hibernate doesn't do anything to synchronize state of the entities in session cache with the DB, unless you request it explicitly.

Usually it's not a problem, because active work usually happens inside a transaction, and operations inside a transaction are not supposed to see changes made by other concurrent transactions (details depend on isolation level, though). So, behavior of Hibernate complements the typical semantics of transaction isolation in this case.

There can also be situations when state of the entity need to be explicitly synchronized to reflect changes made inside the same transaction. It may be caused by bulk update queries or execution of database triggers. In this case you need to request such a synchronization explicitly by calling refresh().

Krems answered 10/9, 2013 at 14:54 Comment(0)
G
2

The first-level (session level) cache ensures that the state of the persistent instances loaded by one transaction is isolated from the changes made by other transactions.

So the changes made by s2 in a different transaction(T2) is not visible when you call s1.get(User.class, 1) in the first transaction, because this time Hibernate will fetch the User from the session level cache s1.

Gloucestershire answered 10/9, 2013 at 15:4 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.