I have read a book on hibernate and reference documentation. But I am not clear in this topic.

Assume I am using optimistic locking with read committed Isolation.

Say I have a conversation which consists Request1,Request2 and Request3.

Request1 : read entity1
Request2 : read entity2
Request3 : update entity1 and entity2.

In this scenario, I understand that if some other request modified either entity1 or entity2 within my conversation span, request 3 will fail and rolled back.
Since Request1 and request2 are reads and don't have any impacts in database, database will be in consistent state even from the conversation point of view.


Now change the scenario.

Request1 : read and update entity1. //Transaction1
Request2 : read entity2. //Transaction2
Request3 : update entity1 and entity2. //Transaction3

In this case, if some other request modified either entity1 or entity2 within my conversation span, request 3 will fail and rolled back.
However update to entity 1 in Request1 is not going to be rolled back, since it would have been committed in Request1.
Database is not in consistent state from the conversation point of view.

please someone clarify if my understandings are correct?

Scenario1:

Request1 : read and update entity1 and commit -> entity.version is set from 0 to 1 (1 is now on database)
OtherRequest : read and update entity1 and commit -> entity.version is set from 1 to 2 (2 is now on database)
Request3 : re-attach entity1 from Request1 to current session without refresh
update entity1 and commit -> entity1.version (1) != version on database (2) --> rollback due optimistic Exception

Scenario2:

Request1 : read entity1 (version =0)
OtherRequest : read entity1 (version =0)
Request1 : update entity1 and commit -> entity.version is set from 0 to 1 (1 is now on database)
OtherRequest : update entity1 and commit -> entity1.version (0) != version on database (1) --> rollback due optimistic Exception

As you can see in both scenarios Database remains in consistent state.

Thanks for the reply. My understanding is that in my second scenario, I can't say database is in consistent state from the logical point of conversation scope



say 'other request' happens in the time between request1 and request 2.

request1 : success : final result entity 1 with version=1 // transaction finished
'other request' : success : final result entity 1 with version=2 // transaction finished
request 2 : done
request 3 : update entity1 and commit : -> entity1.version (1) != version on database (2) ->fails and rolls back transaction.

so from the conversation point of view, it is not atomic, because request 3 has rolled back but request 1 can't be rolled back.

Conversations are not atomic unless you handle all requests it all within one single transaction.
(Did you read somewhere that Conversations are atomic by specification ?)

Thanks. your answers really helped me.
I was bit unclear about that before. I just wanted to confirm my understandings.

So can I say that the advantages of conversation scoped sessions are :(compared to session per request using detached objects)
1) Reduces the number of database hits over the span of conversation.
2) Eliminates the 'Lost update' problem and 'Second lost update' by providing repeatable read over the span of conversation.

Not necessary.
Compared to working with session per request using detached objects,
the number of database hits should be equal if re-attaching the detached objects with Lock.NONE instead to Update.



NO!
Please stop making confusion between 'conversation' and 'transaction'.
Repeatable read-isolatiion scope is the transaction.
Repeatable read is not guaranteed over a whole session-scope or conversation scope.

Ok, in fact in the book 'Java Persistence with Hibernate' on chapter 11.2.1 Providing conversational guarantees theres' written:


On the other hand 2 pages later there's written:



Conclusion: Conversions are not atomic innately, yourself must guarantee it by properly implementing the conversation.

I agree.


I still don't agree.
The persistent context extends some capabilities of the transaction. one of them is repeatable read for entities. So here we have a repeatable read over the span of conversation. Can you think of a situation where you will have 'Lost update' or 'Second lost update' problem occurring over the span of conversation?

yes. I missed this point

Hiberante's persistent context simulates some aspect of repeatable read, but it is not complete.
Consider following scenario:


Last step clearly shows that Hibernate's persistent context does not fulfill all aspects of repeatable read isolation.

Good one. Thanks. I have a good understanding now.

On second thoughts, What you are doing is querying possibly for multiple entities. This is called phantom reads. [even REPEATABLE_READ isolation can't avoid this]
But what I am talking is repeatable read.
Repeatable read is for single entity. you ask for the single entity as many as times you want, hibernate will give you the same entity within the conversation scope.

You're right! Thank you for clarification.

One question that is not clear from the conversation about the repeatable read.. The described scenario is okay because it's a string field and it's loaded by Hibernate once and cached. But what about the complex lazy fields. Consider this scenario:
1. Session created and Human was retrieved, it has a lazy field which was not initialized. The transaction is committed, but session is still open
2. Another transaction removes this Human along with its collections.
3. First session starts a new transaction and initializes the lazy field. What will be the result? This article states that everything will be alright but it doesn't look feasible: