Yes, but the problem is that isolation is Session-wide. ie another Session is not aware of one's lock.
When I set a Lock at level UPGRADE, another Session is able to read a record, which is normal, but as it is not aware that the first one has made a SELECT ... FOR UPDATE. Which means that it will wait to commit its changes until the first one has released its lock. Which will happen when the first one will have committed its own changes, and thus, the second Session will have its changes rejected (StaleObjectStateException - which is normal and expected).
And I didn't find any trace of a way to set a timeout on Session 2's commit. It just waits - like forever - until it's rejected.
So what is the interest of letting user change the lock level ?
As I understand it, the locking system of Hibernate is just an optimistic lock build for internal usage of Hibernate. If the user has to set locks in the application, he must build his own system from scratch.
Am I completly mistaking ?
|