When using generated keys, Hibernate will set the identity propery even if the enclosing transaction is rolled back. This can cause some nasty side effects when you go to saveOrUpdate() that object again, since Hibernate will think it's persistent when it's really not. I understand that Hibernate doesn't rollback entity object state to what it was at the beginning of the transaction. I can expect that for values that I change. What I do not expect is that Hibernate will make my object look persistent when it's not when I'm using generated keys. It seems that it should either rollback the identity value or just not set it until the transaction is committed and we know the data is in the database.

That's why newer hibernates use "y = session.merge(x);". The object passed in as a parameter isn't updated by merge, so you can continue to use it in case of rollback. If the commit works, you use y, which is the persistant version of x.

So, I'm supposed to keep x and y around until after the transaction commits? That's quite a burden to place on all of the pages/components (I'm using Tapestry) in my webapp. How am I supposed to inform them that the transaction has committed and to switch out their x's for their y's?

That depends on what version of hibernate you're using. If your version has session.merge, you could use that: don't record the return value, and query by example on the initial parameter (x in above example) after the transaction commits. Querying by example on a fully-populated object with not id should return the persistent version of that object. Something like:
It must be said that by and large, this problem doesn't come up often because objects involved in a rolled back transaction are usually discarded. At best, they're used to re-populate a form, then discarded. So having a generated id in them isn't a factor. Can you change to working that way?

I am using a TransactionPerRequestFilter, so it can't really talk to all the classes that did work during the course of the transaction.

Depending on the ID generation policy selected, its a fact that the process runs outside of the transaction. It is well known that a sequence, for example in Oracle, is atomic and is not rewound if a rollback occurs. The same applies to the assignment of the Id when using a Sequnce generation policy. So its consistent with database behaviour. I guess the biggest issue is that its something you tend to discover with use rather than pick this up as a matter of reading a manual or tutorial. The solution is not to use the ID's presence as an indication of a successful save operation.

But, I'm not the one using the id to indicate that the object is persisted. Hibernate is. If I want to reuse that object, after a transaction rollback, I'll get an exception from Hibernate because it thinks that the object is a persistent object (since it has an id). And, hibernate caused that object to have an id (which makes it think that it's persistent).

I'm facing the exact same issue. In my scenario my application contains a status object. I set the status to 'success' before committing. If a rollback occurs I want other objects to be rolled back but i want to update the status to 'failed' and re-commit it.
Hibernate tries an update() on saveOrUpdate() since the id value is not an unsaved-value. But the object was never committed :=(

I fixed this problem (and others) by using a UUID for my id property. So, Hibernate isn't generating the id at all, I am. This also solves the hashCode/equals problem.

Thanks. In our physical model we need to use a database sequence as the identifier. I suppose I could add a uuid as a surrogate and add another sequence column.
Hibernate's preferred method would be to create a fresh object and persist it. Shall try to follow that without getting involved in nasty rollback callbacks.