I'm experiencing "stale data" problems with my application, where there are two instances running at the same time. One instance updates a table, the other instance queries the table but gets the old data.

I've tried clear()ing the session, flush()ing the session, using the configuration option hibernate.cache.use_query_cache=false, having the session closed after even small operations (which, I know, is a silly level of granularity in most cases, I just wanted to see if that would help it refresh). I'm not sure what other options are available to me, this is sort of where I've run aground.

Hibernate version is 3.2.6. Database is MySql 14.12 distrib 5.0.51a, using the mysql-connector 5.0.8.

I moved forward with setting hibernate.cache.use_second_level_cache to false, and after it still seemed to be grabbing from cache, changing straight to StatelessSession.

After it still got "old data" I went deeper into the rabbit hole and tried changing the isolation level from 4 (TRANSACTION_REPEATABLE_READ) to 1 (TRANSACTION_READ_UNCOMMITTED) , and immediately started getting the new data.

This implies I'm not committing my transaction -- but I am. I commit it and I get the following from the log :

14:51:35,425 DEBUG org.hibernate.transaction.JDBCTransaction:103 - commit
14:51:35,425 DEBUG org.hibernate.jdbc.JDBCContext:205 - before transaction completion
14:51:35,426 DEBUG org.hibernate.transaction.JDBCTransaction:116 - committed JDBC Connection
14:51:35,426 DEBUG org.hibernate.jdbc.JDBCContext:219 - after transaction completion
14:51:35,426 DEBUG org.hibernate.jdbc.ConnectionManager:404 - aggressively releasing JDBC connection
14:51:35,426 DEBUG org.hibernate.jdbc.ConnectionManager:441 - releasing JDBC connection [ (open PreparedStatements: 0, globally: 0) (open ResultSets: 0, globally: 0)]
14:51:35,427 DEBUG org.hibernate.connection.DriverManagerConnectionProvider:129 - returning connection to pool, pool size: 1


So I guess my question has changed to .. why would hibernate think it's successfully committed a transaction and the jdbc connection itself doesn't? Or alternately, if both sides are accepting that the transaction is properly committed, why would a TRANSACTION_REPEATABLE_READ setting get stale data but TRANSACTION_READ_UNCOMMITTED gets the right data?

Hi,
I have never changed the transaction isolation levels myself, but I did ran into the StaleObjectException during concurrency.
Have you tried something like this:-
Not sure if this is the right way to do or not but this helped in the past. In our application we sometimes do as above but most of the times we throw the same error to the user saying something like:- "Concurrency issue retry again."

Hope this helps,
Latha.