StaleObjectException, but really weird

Question

I have inherited an app, which does some trigger-based inserts and updates and occasionally throws the StaleObjectException. I tried to add a lot of debug (tx,hibernate,type,etc), which has made me even more confused.

15:21:00 Calling dao.insert
15:21:00 starting Trancation T1 
15:21:01 insert records including object #290595
15:21:01 Transaction T1 commits

I see the tx commit in the logs, the hibernate inserts and the data, and indeed object with id #290595 is bound as value. There is a similar insert at 15:24:00, but until 15:25:00 the app is completely silent (No user, no other activity).

15:25:00 Start a Required_new transaction T2
15:25:00 Calling dao.finder
15:25:01 dao transaction uses propagated T2
15:25:01 Select returns object with id #290595
15:25:01 ends propagated transacted finder
15:25:02 calling dao.update
15:25:02 dao transaction uses propagated T2
15:25:02 binds object with id #290595
15:25:02 Could Not Synchronize Database State With Session (StaleObjectStateException)

An sql query in the database reveals that record #290595 does in fact not exist. There are 4 mins between the insert and the failure. Needless to say that is usually works most of the day, but suddenly....

Wouldn't hibernate automatically flush and commit on transaction commit?

I assume the inserts have moved the data to cache but not DB, found again in cache, but refuses to be updated because they are not in DB. So the question is really if anyone have any great ideas?

It is an oracle DB, and I have tried to ensure T2 has Required_new transaction, and with isolation_level serialized, but to little effect.. I'm beginning to think the inserts are somehow left uncomitted,?!

Any suggestions welcom

Answer 1

Well I found the answer myself.

I stumbled upon the javadoc for StaleObjectStateException in Hibernate ver 2:

Thrown when a version number or timestamp check failed, indicating that the Session 
contained stale data (when using long transactions with versioning). Also occurs
if we try delete or update a row that does not exist.

I always assumed the second, never looking at the first..Version was indeed timestamp, and after reading this article as well I modified the version attribute to a long and immediately all errors were gone. Not sure about the discrepancy, but it made no difference to the application logic, so..?

Why would anybody want to use timestamp for versioning anyway?