[hibernate-issues] [Hibernate-JIRA] Commented: (HHH-3442) StaleObjectStateException logs unnecessary stacktrace

[Russell Harmon (JIRA)]

    [ http://opensource.atlassian.com/projects/hibernate/browse/HHH-3442?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=31040#action_31040 ] 

Russell Harmon commented on HHH-3442:
-------------------------------------

log4j has different levels of logging. FATAL is higher (worse) than ERROR. IMO, and afaik in the OP's opinion, he wanted that lowered. I would probably make it somewhere in the debug area since a StaleObjectStateException does not always indicate an error.

I suggest the following code change (modified from the OP's)

Current code:
catch (HibernateException he) {
       log.error("Could not synchronize database state with session", he);
       throw he;
}

Suggested code:
catch (StaleObjectStateException e) {
       throw e;
} catch (HibernateException he) {
       log.error("Could not synchronize database state with session", he);
       throw he;
}

that will log everything except the StaleObjectStateException.

For a user of Hibernate, the only way to prevent it from being logged is to change log4j's logging mode so it suppresses everything except FATAL (don't know how offhand, you could look it up).

> 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.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira