Problem with OptimisticLockType.ALL

samvimes · **Joined:** Wed Nov 04, 2009 10:49 am **Posts:** 4

Hi everyone,
I am fairly new to Hibernate and I have a (hopefully) simple question.

I am using the following code to check if a lock on a dataset has changed.
First I load the current lock.. then I save the object and then I check if the lock has been altered in the database using optimistic locking.

Code:

public void saveObject(T object, LOCK lock){
      Session session = getSession();

      // check if we still have the lock on the row
      LOCK currentLock = (LOCK) session.get(lockClass, lock.getId());

      // do some stuff

      // and rewrite the lock
      session.update(currentLock);
   
   }

The LOCK object is annotated like this

Code:

@Entity
@org.hibernate.annotations.Entity(optimisticLock = OptimisticLockType.ALL, dynamicUpdate = true)

My problem now is that hibernate only checks the lock for changes in the database (by performing an update) if the LOCK object has changed in the session (which I suppose is because of dynamic-update=true). If nothing changed the update is never executed. If I remove the dynamicUpdate attribute hibernate throws an exception because OptimisticLockType.ALL requires dynamic updates.

So is there a way to force hibernate to execute the update or is this the wrong approach?

Best Regards
Carsten

samvimes · **Joined:** Wed Nov 04, 2009 10:49 am **Posts:** 4

What I forgot... transaction management is handled by Spring ;)

mmerder · **Posted:** Wed Nov 04, 2009 12:16 pm

What do you need that LOCK for? Did you have a look at the locking strategies, hibernate supports?

samvimes · **Joined:** Wed Nov 04, 2009 10:49 am **Posts:** 4

I develop a web application and I use the LOCK object to ensure that the edited object (e.g. a user object) is only changed by one application user at a time (no concurrent access). The LOCK object is nothing more than a mapped object to some database table columns containg locking information.

So if a app user want to edit e.g. a user object

1. The lock is obtained for the user
2. The user makes changes to the object
3. When the user saves the object I check if he/she still has the lock to make sure no other app user has changed the data
4. I update the data
5. I check again if the user has the lock before commiting anything. This is done via optimistic locking.

Well I thought optimistic locking IS a strategy supported by hibernate? And I cannot use a version column, so I tried it with optimistic lock type all.