CODEWITHSUNDEEP
javahibernateweb
friko
friko

Reputation: 607

Sharing session entities

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.

Upvotes: 1

Views: 164

Answers (3)

Henry Leu
Henry Leu

Reputation: 2274

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

Upvotes: 0

Affe
Affe

Reputation: 47954

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

Upvotes: 1

efan
efan

Reputation: 968

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.

Upvotes: 0

Related Questions