StaleObjectStateException logs unnecessary stacktrace ----------------------------------------------------- Key: HHH-3442 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3442 Project: Hibernate3 Issue Type: Improvement Affects Versions: 3.3.0.GA Reporter: Tom van den Berge Priority: Minor When using optimistic locking, and stale state is detected, a StaleObjectStateException is thrown. This exception is caught in AbstractFlushingEventListener, logged as error, including a stacktrace, and then thrown again. It would be better not to log the stacktrace in this situation, since it's up to the client code to deal with the exception. If the client code doesn't handle optimistic locking exceptions, it can choose to log the stacktrace itself, or otherwise do something useful with the exception, such as retrying. Currently, the stacktrace is always logged by Hibernate, also if the client code recovers from the exception, which is a bit confusing when looking at the logs. Also the fact that this particular exception is logged with severity ERROR is inappropriate. It's up to the client code to decide if it's an error. I suggest the following change to AbstractFlushingEventListener: Current code: catch (HibernateException he) { log.error("Could not synchronize database state with session", he); throw he; } Suggested code: catch (StaleObjectStateException e) { log.warn("Could not synchronize database state with session", e.getMessage()); throw e; } catch (HibernateException he) { log.error("Could not synchronize database state with session", he); throw he; } -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators.... - For more information on JIRA, see: http://www.atlassian.com/software/jira