[hibernate-dev] PERSIST_ON_FLUSH.noCascade()

The fix for HHH-1822 throws TransientObjectException when PERSIST_ONFLUSH is not cascaded to a transient entity. Should this still be the behavior according to JPA 2.0? I believe that the expected behavior is defined by JPA 2.0, section 3.2.4 "Synchronization to the Database", specifically: "For any entity Y referenced by a relationship from X, where the relationship to Y has not been annotated with the cascade element value cascade=PERSIST or cascade=ALL: • If Y is new or removed, an IllegalStateException will be thrown by the flush operation (and the transaction marked for rollback) or the transaction commit will fail." It sounds to me that TransientObjectException is the wrong exception. Am I misinterpreting this or taking it out of context? Related, the work I did for HHH-6957 throws PropertyValueException when an insert depends on a non-nullable, transient value. I agree that PropertyValueException is more meaningful than IllegalStateException/JDBCException. I want to confirm that this isn't going to be a spec violation. I see some other problems with HHH-1822, particularly after HHH-5472 (re-orders inserts when there are dependencies on non-nullable transient entities) was fixed: 1) it doesn't take into account that there may be another cascade path that will persist the transient entity 2) it doesn't take into account that the transient entity may already be in the process of being saved (i.e., in the cascadeBeforeSave phase). In case 2), if the transient entity is the association owner, then TransientObjectException would be thrown erroneously, because the current entity being saved must be saved before the transient entity. This is what causes HHH-5299. I can extend the work I did for HHH-6957 to also look for nullable, transient values. At the end of session.persistOnFlush (when the cascade level == 0), the appropriate exception (whatever is decided) could be thrown. I believe this would cover both cases. IIUC, then PERSIST_ON_FLUSH.noCascade() would no longer be needed. If so, can we deprecate CascadingAction.requiresNoCascadeChecking() and noCascade()? (As an aside, another improvement could be to delay inserts until all transient references (not just non-nullable) are resolved, if possible. This would avoid nullifying the transient reference on insert and requiring an update on flush. If it's not possible, the behavior would be as it is currently.) Please provide some feedback so I can proceed with fixing HHH-5299. Thanks, Gail