i think this is a very common case:

in a transaction,load an object from database,check some attributes of the object to determine whether you can update the object.

try{
tx=session.beginTransaction();
Foo f=(Foo)session.load(Foo.class,id);
if(f.getSomeFlag()){
throw new YouCannotUpdateFooException();
}else{
f.setSomeAttr("someAttr");
}

tx.commit();
}catch(Exception e){
if(tx!=null)
tx.rollback();
throw e;
}

(the isolation level of my database is greater than repeatable-read.)
i don't know in which LockMode should i load (Foo f),LockMode.UPGRADE?
or just the default LockMode.NONE?
(if session.load() load the object from the database,i think the default LockMode.NONE is ok,but it may load the object from cache)

and the Hibernate api doc say that you should spend much time worrying about locking except you are an "advanced" users.

thanks a lot.

Hmmmmm. This is interesting. Currently the lockmode doesn't affect whether we hit the cache. If the object is in the cache already, it will just lock() it after pulling it from the cache (in the case of versioned data, lock() does a version check).

However, I can see a really strong argument that for lockMode > LockMode.NONE, we should ignore the process-level cache altogether. I think I will make that change.

Thanks,Gavin.

i must ensure that between i checking the flag and updating the object,
other threads can not change the status of the object.

can i add a <version> property and catch the StaleObjectStateException to avoid concurrent update?

Whaddayamean "catch"?


StaleObjectStateException occurs during flush() and is unrecoverable.

I think a StaleObjectStateException means concurrent update between checking the flag and updating the object, so I can try again until
no StaleObjectStateException thrown.

Anyone help me?

Thanks.