Hi all

Version: Hib 2.1

I have asked how to disable Session Level Cache before in the forum and I have told that it cannot be disabled. I have performed a test:



Then, I have changing the value of the record during the execution of the program and I found that the value get returned from Hib didn't get updated. Since, I have multiple programs accessing the database, how can I ensure some exclusive access to the data? I need this for key generation.


Thanks
[/code]

There is no meaning to dissable it (It has meaning if transactions are dissabled too). Just use sequence or some UID generation algorythm there is nothing dependant on session cache, transactions isolate your applications in the same way too.

hm... I am working on a existing application that I want to migrate it to Hib. I need to use the key table to manually create the sequence numbers.

If I can't disable second level cache, is there anyway to lock the record at the time it is being retrieved?

Thanks!

Hi all

I have tested if the transaction is working properly when there are more than one program access the DB. The following simple program generate 10000 keys and I run another program that also generate 10000 keys.



The second program uses direct SQL to generate the key -

"update keytable set nextkey = nextkey + 1 where keyId = 1"

However, when the program finishes the nextkey value only increased by 18554 and there was about 1500 keys missing.


I have run Two second programs at the same time, then no key is missing. So, it is should not be the problem in the DB.


Does anyone know how to do this? Please Help!

You can use session.load(object, type, LockMode.UPGRADE) for explicity pessimistic locking.

I updated the code as below:




However, when I run the test again - run this program and run another program that executes "Update KeyTable set NextKey = NextKey + 1 where KeyId = 1" for 10000 times, I found that the key only increased by 10853 and there were still keys losted.

Thanks for your advice!

This key generation algorythm depens on concurency control algorythm.

"update keytable set nextkey = nextkey + 1 where keyId = 1"

This SQL statement is executed this way:

Transaction puts read lock selects record(key = 1), puts write lock and increases nextkey. Two transaction can read/read or read/write value concurenty, but not to write/write. As I understand DB must reject one of transactions if both transactions read the same value before one write.

T1( r ) ->T2( r )->T1(w)(rw lock, wait T2 )->T2(r)(rw lock, wait T1)

It looks lik deadlock, is not it ?

Well, this will work:

aEmp = (Employee)session.load(Employee.class, aPK);
session.lock(aEmp, LockMode.UPGRADE);
session.refresh(aEmp);
Transaction tx = session.beginTransaction();
aEmp.setXxx(xxx);
...
tx.commit();

To refresh() after lock() will let the 2nd concurrent thread re-read database after the blocking of lock is released. I tested it in the ThreadLocal pattern where there are separate Hibernate sessions maintaining different copies of PO relative to the same db record.
Also, Oracle9 dialect is used to ensure DB native lock scheme.

I think the main issue is that both session.lock() and session.load() with a nontrivial LockMode lock the record AFTER the data is retrieved. There is no method in Hibernate Session to lock BEFORE retrieve.

Do you realize that load() and get() can specify a LockMode

YES!

LockMode just inserts the appropriate locking hints to the query, it is still your job to lock at the right points, just like you'd have to do with plain JDBC.