My team is using Hibernate 3.1 for a fairly simple web-based data entry system. In our work flow, the object graph is only persisted after the user is done with all modifications and editing. In other words, they create a Foo object, which is held in their HTTP session, and once they have it the way they want it, Hibernate is called to persist the Foo object to the database. We have a unique constraint on the database for our Foo objects, and we are allowing that constraint to break an attempt to persist new objects, rather than using a query to determine if the new object violates the constraint.

Now, the issue. Our objects use surrogate keys, generated from an Oracle sequence. When Hibernate fails to persist an object due to a database constraint, we rollback the transaction and let the user keep working to resolve the issue. However, Hibernate leaves the object's identifier set to the newly-pulled sequence ID even though the object is still transient, which causes Hibernate to mistakenly think we're trying to update a dirty record the next time save is called for the user's object. It seems to us that if a transaction is rolled back for an object that was to become persistent, Hibernate should restore the generated identifier values to their original state, rather than leaving the now useless sequence ID in there.

My development team agrees that this seems to be a failing of Hibernate to follow the spirit (if not the letter) of the transaction contract, and I wanted to see what the Hibernate community thought of this behavior before logging it in JIRA as a bug.

Also, please refrain from recommending that the database constraint be removed; I'm aware that hibernate considers them redundant, but we do have legacy applications touching this data, and removing the constraints would be just ASKING for trouble. :)

-- Kin