1

Let's say we have a web application using Hibernate. My question is about what happen, if two different transations from different users, access and manipulate the same entity ? For example we have an entity named 'Student' and it has a field 'age'. Now, two different transaction from different users, fetch that entity using Hibernate session e.g :

Student student = session.load(1); // 1 is the id of some student

and then one user manipulate the age fields e.g: student.setAge(12); Does the second user see that change in completely another transaction ? I mean if the second user invokes in his own transaction student.getAge(), does he see the new value - 12 ? Notice, that the first user, who changes the age property, didn't commited the transaction yet.

friko
  • 567
  • 2
  • 7
  • 20
  • Provide full program to get clear idea. Generally in a web application, two different transactions will use two different objects of `Student` entity. – Ravindra Gullapalli Mar 01 '13 at 20:44

3 Answers3

1

That's only partially a hibernate question. Whether or not other users see uncommitted data depends on if you've changed the isolation level of your database connections to read-uncommitted. There aren't too many valid reasons you'd ever want to do that, and hibernate will default it to read-committed unless overridden. So in general, no, other users will not see changes until the transaction is committed.

In the event you have reduced the isolation level, then it comes down to when the SQL actually gets sent to the database. This is based on hibernate's flush settings and can be a bit hard to predict in multi-tiered systems. But basically calling setAge is not going to send SQL to the database that others can see. Something that causes a flush has to happen, what those things are is again configuration dependant.

Further note that if the second session loads an entity before the update is committed, even if the first session commits an update, that second session will not auto-magically update its in-memory entity unless you explicitly call refresh on it. e.g.,

Time 1: Session A loads Student 1
Time 2: Session B loads Student 1
Time 3: Session A sets new age and commits
Time 4: Session B gets Age, will still see old value
Time 5: Session B calls refresh on Student 1
Time 6: Session B gets Age, will see new value set in Session A
Affe
  • 47,174
  • 11
  • 83
  • 83
0

Please look here: Hibernate session thread safety. I think it is very similar to what you ask. Basically it's not a good idea to use session in multiple threads. Thus assuming your are using different sessions, second user won't see changes.

Community
  • 1
  • 1
efan
  • 968
  • 6
  • 11
0

Hibernate is good at concurrently updating in multiple threads as this case.

Firstly, thread-safety problem doesn't exist in this case. because each transaction hold its own session, each session will hold its loaded objects in its so called first-level cache respectively. the two instance in the two threads won't see each other,

Secondly, optimastic-locking mechanism will work when multiple transactions update the same record. it is first come first serve model. the first commited transaction secceeds, the second commted transaction will fail throwing an exception. because hibernate will check versin property to see if the version is the original version before its updation operation commits.

see http://docs.jboss.org/hibernate/orm/3.3/reference/en/html/transactions.html

Henry Leu
  • 2,184
  • 4
  • 22
  • 34