Cascades with assigned identifier in children not saving in 3.0.5 ----------------------------------------------------------------- Key: HHH-897 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-897 Project: Hibernate Core Issue Type: Bug Components: core Affects Versions: 3.0.5 Environment: Hibernate 3.0.5, Oracle 9i, Spring 1.2.2 Reporter: Rick Birch In section 22.4 of the Hibernate manual, the manual describes the correct action that should be taken when a cascaded subclass is being saved/updated: Well, that's all very well for the case of a generated identifier, but what about assigned identifiers and composite identifiers? This is more difficult, since Hibernate can't use the identifier property to distinguish between a newly instantiated object (with an identifier assigned by the user) and an object loaded in a previous session. In this case, Hibernate will either use the timestamp or version property, or will actually query the second-level cache or, worst case, the database, to see if the row exists. However, the code that does that in the BasicEntityPersister class public Boolean isTransient(Object entity, SessionImplementor session) method can never get to the second-level cache check. .... // check the id unsaved-value Boolean result = entityMetamodel.getIdentifierProperty() .getUnsavedValue().isUnsaved( id ); if ( result != null ) return result; // check to see if it is in the second-level cache if ( hasCache() ) { CacheKey ck = new CacheKey( id, getIdentifierType(), getRootEntityName(), session.getEntityMode(), session.getFactory() ); if ( getCache().get( ck, session.getTimestamp() ) != null ) return Boolean.FALSE; } If result from the entityMetamodel.getIdentifierProperty() .getUnsavedValue().isUnsaved( id ); is not null, then this if statement will return a result. The Cascades.isUnsaved(id) method always returns a Boolean value, so the if (hasCache()) check can never be reached. public Boolean isUnsaved(Serializable id) { return id==null || id.equals(value) ? Boolean.TRUE : Boolean.FALSE; } For us, we'll be changing to generated keys. But the assigned strategy works better with Unit Test code, allows for more predictable results. Apologies in advanced if this is already fix in 3.1, but I didn't see any reference that I could interpret in the release notes for 3.1 beta.