Ok, I think I've figured it out.
the exception is thrown from org.hibernate.event.def.AbstractFlushingEventListener.java:301
Code:
protected void performExecutions(EventSource session) throws HibernateException {
log.trace("executing flush");
try {
session.getJDBCContext().getConnectionManager().flushBeginning();
// we need to lock the collection caches before
// executing entity inserts/updates in order to
// account for bidi associations
session.getActionQueue().prepareActions();
session.getActionQueue().executeActions();
}
catch (HibernateException he) {
log.error("Could not synchronize database state with session", he);
/* line # 301*/ throw he;
}
finally {
session.getJDBCContext().getConnectionManager().flushEnding();
}
}
Logging this exception in line # 300 makes sense in all cases except for one - when optimistic locking is used. In that case the exception is an instance of org.hibernate.StaleObjectStateException (caught as HibernateException) and that when rethrown should be handled properly in the client code. This usually means - "another thread or process won the race for this particular object and updated/deleted it - so take appropriate steps or just ignore it and find yourself another object to work with".
In my oppinion logging this exception on the error level is a misuse, since it may trigger actions that are not adequate to the cause - for example (depending on the logging framework configuration) an email or a text message informing about this "error" may be sent to the system administrator whereas this in fact is not an error and is handled in the client code.
On the other hand, suppressing this class in the logging framework configuration so it is not capable of logging messages seems not to be a good option either.
Login
FAQ
Search