Hibernate version:
-2.1

Mapping documents:

Code between sessionFactory.openSession() and session.close():
-all done in springframework

Full stack trace of any exception that occurs:

You know the exeption I'm talking about!

Name and version of the database you are using:
Oracle 9i


Ok so last week I was dying to post to this group. We were having optimistic locking problems all the time in this particular process. So we put a couple of debugs into our persistent objects and found that the cacheversion field was getting updates all the time. Even on finds! So something was seriously wrong. This was leading to the optimistic locking exception when we were doing the saves like 4 steps later. So instead of posting here I first downloaded the src for hibernate 2.1 and put some debug statements in there. Turns out I could have run it with trace but that's never fun to me. Actually we started with some Thread.dumpStackTrace() calls in the persistence objects to see who was updating these cache versions. Once the finger was pointed at the SessionImpl class I got down to business running eclipse with the src of hibernate and debugging.

Turns out dirty flags were being set in a sub collection of a particular object I was 'finding'. This was happening because the getSomeCollection method was SORTING the collection before it gave it back. This was causing a get when the object didn't have the collection to be sorted( it's lazy ) then since it got them and resorted them the object was now calling them dirty and updating the cache version.

So the point here is debugging hibernate is not that bad. You might learn something. Also be careful what you do inside your persistence objects. And try watching the sql sometime you might be suprised what you see.

-Robert