It would be easier to help if you were more precise. I searched the Hibernate
source for the error you mentioned, didn't find anything, and then noticed the
obvious typo.

The "don't flush" ... error only showed up 1 time, in
DefaultFlushEntityEventListener.

Here's the code:

public void checkId(Object object, EntityPersister persister, Serializable id,
EntityMode entityMode)
throws HibernateException {

if ( id != null && id instanceof DelayedPostInsertIdentifier ) {
       // this is a situation where the entity id is assigned by a
post-insert generator
       // and was saved outside the transaction forcing it to be delayed
       return;
}

if ( persister.canExtractIdOutOfEntity() ) {

       Serializable oid = persister.getIdentifier( object, entityMode );
       if (id==null) {
               throw new AssertionFailure("null id in " +
persister.getEntityName() + " entry (don't flush the Session after an
exception occurs)");
       }
       if ( !persister.getIdentifierType().isEqual(id, oid, entityMode) ) {
               throw new HibernateException(
                               "identifier of an instance of " +
                               persister.getEntityName() +
                               " was altered from " + id +
                               " to " + oid
                       );
       }
}

}

Now Hibernate needs to do 2 things - it needs to persist an object to the
database, and it needs to get the persisted values reflected in the object. I
will not pretend to be a Hibernate expert - here's a few SWAGS:

Given that the class is called DefaultFlushEntityEventListener, Hibernate has
decided it's time to do a flush - that is, actually commit your insert/update
to the database. Given that the error occurs in the method checkId, it has
nothing to do with the surrogate key you mentioned earlier.The id is null -
and Hibernate does not know how to resolve it. If this is an update, it's a
programming error. But it sounds like it's an insert.

The hashcode method in your class is scary. It returns a constant -1. This is
bad. I don't know if it is relevant or not. Is there any chance this would
cause Hibernate to do an update when an insert is expected? I dunno. Remove it
or improve it. Seriously. No hashcode is better than this.

Hmm, looking at the Hibernate code again, I wonder if that is the issue. If
the id was not null, it would return from the first if statement:

if ( id != null && id instanceof DelayedPostInsertIdentifier )

So the id is null.

So the persister thinks it can extract the id from the entity ..

if ( persister.canExtractIdOutOfEntity() ) {

       Serializable oid = persister.getIdentifier( object, entityMode );
       if (id==null) {
               throw new AssertionFailure("null id in " +
persister.getEntityName() + " entry (don't flush the Session after an
exception occurs)");

But it fails. I have not looked at the persister code. Again, a swag or 2 ...

1) Some thing is wrong with your code. Hibernate thinks the save is an update.
It needs the id.

2) Something is wrong with the annotation. It looks ok to me, but I don't use
MySql. At this point, we're talking about issues specific to the RDBMS used.
How is Id defined in the database? Some serial type? Does MySql use sequences
(Oracle and Postgres do)? Is this the appropriate annotation for a PK given
it's datatype for MySql? I dunno.

But I do know that Hibernate's persistor thinks it can get the id from the
object and fails.

HTH

Eric