Hi,

I am new in using hibernate and found an article related to "Open Session in View" pattern and have somes questions.
http://www.hibernate.org/43.html

1. Can I lock the records (by select for update) when the first request arrived on the server, and then display the data on the page, after user updated the data and click submit, I update the records and commit the transaction?


2. Does the impact of currentSession.getTransaction().commit() in the HibernateSessionConversationFilter same as the database transaction commit? e.g. the data are persisted in database.

3. I read the book Java Persistence with Hibernate (REVISED EDITION OF HIBERNATE IN ACTION) and it mention the sequence of the Interception of events to manage the lifecycle of a Session in figure 11.4 as follow

A. the first transaction (first request)
1. s = sf.openSession()
s.setFlushMode(MANUAL)
MSC.bind(s)
2. s.beginTransaction()
3. s = MSC.unbind()
4. commit()

B. the second transaction (second request)
5. MSC.bind(s)
6. s.beginTransaction()
7. s = MSC.unbind()
s.flush()
8. commit()
9. s.close()

Why it call commit() at the first transaction ? (in the step 4), Does this commit will persist the data to database and cannot be rollback on the second transaction?

Indeed, when you commit the transaction, the data is definitely persisted to the database. So, when the request comes in, you grab your session and even open your transaction. THen you do everything, including accessing your data during the view operation of your JSP, and then your transaction gets comitted, and everything that is part of that transaction, and part of that session's transaction, is persisted to the database. It's all very elegant and fairly simple!

Hi, Cameron McKenzie

Is it mean that we must commit every transaction within the session?

Can I lock the record on the first request and then update and commit it at end of the conversation? (e.g. Pessimistic Locking)

For example, when use request a web page to update the record, I lock the record first (be select for update) and show the web page for user to update. (At the moment, other users cannot update this record) After updating, the user will click on a button, when I receive this second request, I update the record and commit this transaction to release the lock of the record for other user update. (similar to the client server logic)

You definitely don't want to lock the record over multiple request-response cycles. I mean, what if the person never clicks again. Then that record will have a really long lock.

Just open and close the session with each request-resposne cycle. WHen the user is ready to commit, commit everything - open the session, write to the database, commit and close. That's all there is to it!