Hibernate version: 3.0.5

Code between sessionFactory.openSession() and session.close():

Transaction tx = session.beginTransaction();
List fixes = session.createCriteria(Fix.class).list();
tx.commit();


Name and version of the database you are using:
Apache Derby, 10.0.2.0

The generated SQL (show_sql=true):

Hibernate: select this_.FIX_ID as FIX1_0_, ... from FIX this_
Hibernate: update FIX set VERSION=?, ... where FIX_ID=? and VERSION=?
Hibernate: update FIX set VERSION=?, ... where FIX_ID=? and VERSION=?
Hibernate: update FIX set VERSION=?, ... where FIX_ID=? and VERSION=?
Hibernate: update FIX set VERSION=?, ... where FIX_ID=? and VERSION=?
Hibernate: update FIX set VERSION=?, ... where FIX_ID=? and VERSION=?



In my application, there is class Fix, that has field:
private int version; // for optimistic locking

When executing the code shown above, Hibernate will issue an "update" when the transaction is committed, which increases the version counter (see the generated SQL, as shown above - there are 5 objects returned by the select).

Now my question is: why does Hibernate issue the update, even when there was no session.update()?
I found this behaviour at all isolation levels (1, 2, 4).

This might result in one of two concurrent readers (both executing the same above code) receiving a StaleObjectStateException at Transaction.commit().

I've read the book and browsed the forum, but couldn't find an aswer to that question. Mabe I'm overlooking s.th.?

I'm seeing the same behaviour. Anyone know what's going on here?

I had experienced the same problem
hibernate was updating the version of a certain table when i was doing session.find() , don't know what exactly was causing it, but i have managed to solve it with session.clear() before find(). Hope it'll help and if somebody knows what is causing such behavior please do tell.

BTW, to be more specific, it's the flush that triggers the update. (The original poster reported that it was the commit, which is true because it calls flush.)

hibernate issues SQL UPDATES at flush time because it thinks that domain entity is dirty.

find out why it thinks the thing is dirty. typically, if unexpected, this is due to bad equals() implementations.

I found the cause of my problem.

When I added optimistic locking, I copied and pasted my @Id methods because they are pretty similar to how I wanted my @Version methods to look.

Unfortunately I left too much of the @Id accessor in the @Version accessor. My getVersion was returning the object's key! This is what caused the update to trigger.

I'm sure Steve's explanation is right for most people, but I just thought I'd add another avenue for anyone searching the forum archives. (And, of course, confession is good for the soul.)