Quote:
It probably has to do with the granularity of the timestamp. I had the same problem using a <version type="timestamp"> mapped to a java.util.Date property
It could also have to do with timezone offsets and whatnot. Oracle has TIMESTAMPE WITH [LOCAL] TIMEZONE
another clue, if we do a session.refresh before the delete, the timestamp is reloaded from the DB and everything works as expected, this problem only occurs when the timestamp on db ends with 0000000000 (if not it works even without refresh, the probability it happens is low I know)
doesn't seem a timestamp handling problem
our db is oracle and we've the latest hibernate 2.x