Need help with Hibernate? Read this first:
http://www.hibernate.org/ForumMailingli ... AskForHelp

3.2.1.ga:

Mapping documents:

Code between sessionFactory.openSession() and session.close():

Full stack trace of any exception that occurs:

Oracle 10g

The generated SQL (show_sql=true):

Debug level Hibernate log excerpt:


Problems with Session and transaction handling?

Read this: http://hibernate.org/42.html


Hello,

I am just playing around with pessimistic locking and I need a bit of clarification. I tried using two notations to use pessimistic locking.

1. call session.get(Class, id, LockMode)
2. call session.lock( Object, LockMode)

The first option behaves as I would expect it to with "select for update". If there are two threads T1 and T2, the second thread T2 will block on the line. After T1 commits T2 will continue. T2 will read the new values committed by T1.

However the second notations with session.lock (Object, LockMode.UPGRADE) is confusing me a bit. In the second case T2 will block as well and continue after T1 commits. When T2 unblocks and performs a read it will not see changes committed by T1.

What is the purpose of this second notation? Even though it blocks it doesn't pick up committed changes by T1. I am using Oracle with default read-committed isolation.

Thank you.

Read commited depends on when the read/tx occured/started.

Thanks David,

My apologies I did not understand your reply/question. In both cases I start a transaction right before executing a query on the session object and I commit right after updating the value.

Hi,

Is the above snippet the code that is run by both threads? The read happens before the lock. Assume T1 runs and does iterator.next(). Before it gets the lock, T2 gets to run and does the read. At this point there's no lock yet and hence T2 gets the current value. Then T1 gets to run and gets the lock. At this point T2 is blocked until T1 commits.

Thanks for your reply,


Yes the code is run for both thread and I agree with your statement. My questions is how is then that syntax:

session.lock(capabilityEntity, LockMode.UPGRADE)

used for pessimistic locking since T2 will do a read before T1 locks. How do you ensure that T2 can not do a read before T1 locks, something like "select ... for update".

Is the proper way of using a pessimistic locking first to issue a query that retrieves ids and then do a

session.get ( Class, id, LockMode)

which will ensure that T2 can not do a read before T1 locks?

Thanks for your help,

I see your point now.

I don't think session.lock() is intended to be used that way.

session.lock() will perform a version check and if it detects that another transaction has modified the object, it will throw an exception.

You can give it a try (I did).
You need to have the "version" element in your mapping file and Pojo.


Now you might say that this is the same as setting optimistic-lock="version".

There's actually a slight difference. With optimistic locking, the detection is done at commit. With session.lock it is at the time the call is made.

Budyanto

Thanks himawan for your replies,

Thanks for your input, I know I can always use optimistic locking with LockMode.READ to verify whether object has been modified by another transaction. I just wanted to figure out how pessimistic locking works, I see also that you can specify LockMode.UPGRADE_NOWAIT which will work properly for pessimistic locking.

Anyways thanks for your help.