A thread about it: http://forum.hibernate.org/viewtopic.php?t=931005

Conditions to recreate:
1. Create a new hibernate session (and transaction, if desired)
2. Create a transient object (that hibernate can persist)
3. Place the transient object in a known bad state (so that any attempt to persist it will fail)
4. Attempt to save the object, which will fail
5. Close session, rollback txn
6. Fix the error with the object
7. Create a new hibernate session/txn
8. Attempt to save the object (which will currently fail, though it should not)
9. Close session

The error occurs at step 8. Because hibernate does not set the ID of the object to null, it will assume that the object is in the database. When hibernate attempts to update the object (rather than save), it will fail. This bug is particularily nasty when dealing with cascades, as all objects will be assigned numbers.

A workaround:
Have your DAO layer keep track of new objects and manually set the ID to null /after/ the session has closed (if you delete the ID before the session closes, hibernate will complain about the changing of IDs).

This workaround can get quite messy, however, if one requires the use of cascades.

A (possible) real fix:
Have hibernate keep track of all new entities in the session, and upon failure, iterate those entities and set their ID to null.

Another possibility (enumerated by gavin in the thread mentioned above) is to copy the entire object tree by value, but this could cause real problems in objects with large byte arrays.

The problem may be difficult to fix, however, I find the fact that the steps outlined above do not work to be very counterintuitive. If not fixed, this bug should be at the very least well documented.

The exception handling portion of the documentation does not indicate that all newly saved objects must be thrown out if the session they are saved in has an exception.