I can see the same warning being logged and it seems to be an issue with the way generated IDs are being handled.
With a (simple) mapping definition:
Code:
<class name="com.example.Person" table="PERSON" lazy="false">
<id name="id" type="long">
<generator class="native"/>
</id>
<property name="name" type="string" not-null="true"/>
</class>
... and code that attempts to saveOrUpdate it (with no id set - expecting a new generated id) the warning is logged every time. Tracing back from the code mentioned by @ryan the code in org.hibernate.id.IdentityGenerator.GetGeneratedKeysDelegate.executeAndExtract(PreparedStatement, SessionImplementor) will obtain a ResultSet that the JdbcCoordinator doesn't know about:
Code:
public Serializable executeAndExtract(PreparedStatement insert, SessionImplementor session) throws SQLException {
session.getTransactionCoordinator().getJdbcCoordinator().getResultSetReturn().executeUpdate( insert );
ResultSet rs = null;
try {
rs = insert.getGeneratedKeys();
return IdentifierGeneratorHelper.getGeneratedIdentity(
rs,
persister.getRootTableKeyColumnNames()[0],
persister.getIdentifierType()
);
}
finally {
if ( rs != null ) {
session.getTransactionCoordinator().getJdbcCoordinator().release( rs );
}
}
}
In the above, getGeneratedKeys() is going to (always?) give a ResultSet that is not in the JdbcCoordinatorImpl's collections. Which explains why the warning is seen for every insert where an ID is generated.
It seems like a minor bug - perhaps the rs needs to be registered or the logging changed? I'd appreciate it if anyone could confirm. I guess the work around in the mean time is to turn down the log-levels for org.hibernate.engine.jdbc.internal.JdbcCoordinatorImpl.JdbcCoordinatorImpl?
Login
FAQ
Search
