I've been trying to do batch processing in Hibernate and so far it seems to work fine. However, I've been running into problems whenver an exception occurs. Basically, this is the code that I'm running:


Session session = sessionFactory.openSession();
Transaction tx = session.beginTransaction();

for ( int i=0; i<100000; i++ ) {
try {
Customer customer = new Customer();
customer.setValue1();
customer.setValue2();
customer.setValue3();
..
..
session.save(customer);
} catch (Exception e) {
// log and ignore
}
}

tx.commit();
session.close();


So basically if an exception occurs during a save, I just log it and move on to the next one. Is there something else I should be doing - such as flushing the object from the session?

What happens is, after this exception occurs, when it tries to save the next Customer object, I get this exception:


- error in batch commit changes : org.hibernate.AssertionFailure: null id in entry (don't flush the Session after an exception occurs)
- an assertion failure occured (this may indicate a bug in Hibernate, but is more likely due to unsafe use of the session)
org.hibernate.AssertionFailure: null id in entry (don't flush the Session after an exception occurs)
at org.hibernate.event.def.DefaultFlushEntityEventListener.checkId(DefaultFlushEntityEventListener.java:49)
at org.hibernate.event.def.DefaultFlushEntityEventListener.onFlushEntity(DefaultFlushEntityEventListener.java:82)
at org.hibernate.event.def.AbstractFlushingEventListener.flushEntities(AbstractFlushingEventListener.java:190)
at org.hibernate.event.def.AbstractFlushingEventListener.flushEverythingToExecutions(AbstractFlushingEventListener.java:70)
at org.hibernate.event.def.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:26)
at org.hibernate.impl.SessionImpl.flush(SessionImpl.java:730)
at org.hibernate.impl.SessionImpl.managedFlush(SessionImpl.java:324)
at org.hibernate.transaction.JDBCTransaction.commit(JDBCTransaction.java:86)
....
....
....


Any ideas?

I am getting a similar problem when doing unit tests I think. In setup I start the transaction, in the test case I insert the record and in tear down I commit.

When I insert (using my DAO) I call flush, and I want it to throw a constraint violation exception. I log that but then when I get to commit it seems to flush again and throws the same exception.

jt_1000 just posted the solution to this problem in my thread (I think we had the same problem)
http://forum.hibernate.org/viewtopic.php?t=955990

The API doco states
If the Session throws an exception, the transaction must be rolled back and the session discarded. The internal state of the Session might not be consistent with the database after the exception occurs.

See
http://www.hibernate.org/hib_docs/v3/ap ... ssion.html

Ouch! Does that mean we have to rollback the entire transaction and discard all of the objects that were inserted successfully?

Yes - according to the doc you need to rollback.

and yet, you can merge the good objects back into the new session, which helps a bit.

IMO - I really don't see why the sess.evict (..) can't just kill the object from hibernate mgmt (as cedrick originally tried to do).
.... perhaps an enhancment request.

The evict wouldn't work in our case anyways because we're using autogenerated ids. Hibernate would complain about not the object having a null id since the save failed.

The IDs are assigned to the objects when you invoke save, and if the flush fails (the actual insert/update) and you rollback the "DATABASE" transaction, you'll notice the objects will still have the ID's business state prior to the Exception. As such, you can merge those objects into a new Session (even though they are auto-gend-ids), and invoke save/(flush if needed) again and it should work.