[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-2770?page=c... ] Jürgen Kellerer edited comment on HHH-2770 at 5/4/11 5:04 AM: -------------------------------------------------------------- Even if this case is old, I'd like to add that there's one more, really important use case that could be addressed with action observers if they can be registered through a (hibernate specific) public API or through service loading. Occasionally it's quite hard to trace why a particular action failed during a flush of many queued actions (especially with high concurrent load). This is the case as the exceptions that are thrown do not include "toString()" or similar of the entities that failed and as a result one needs to work out the problem with DB exceptions which are usually not really helpful either. Under normal circumstances it's also not efficient to keep all persisted and updated instances externally as this causes lots of overhead and design issues. While statement logging is an option for debug systems, it doesn't really help if the error appears in a system being in production. Basically an action observer (if designed that way) could not only observe the execution of an action but also observe the exception that may be thrown. If designed that way an observer can be registered that logs parts of the action queue or at least the entity that failed, making it a lot easier to trace why things went wrong. was (Author: juergenk): Even if this case is old, I'd like to add that there's one more, really important use case that could be addressed with action observers if they can be registered through a (hibernate specific) public API or through service loading. Occasionally it's quite hard to trace why a particular action failed during a flush of many queued actions (especially with high concurrent load). This is the case as the exceptions that are thrown do not include "toString()" or similar of the entities that failed and as a result one needs to work out the problem with DB exceptions which are usually not really helpful either. Under normal circumstances it's also not efficient to keep all persisted and updated instances externally as this causes lots of overhead and design issues. While statement logging is an option for debug systems, it doesn't really help if the error appears in a system being in production. Basically an action observer (if designed that way) could not only observe the execution of an action but also observe the exception that may be thrown. If designed that way an observer can registered that logs parts of the action queue or at least the entity that failed, making it a lot easier to trace why things went wrong. -- 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

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-2770?page=c... ] Jürgen Kellerer commented on HHH-2770: -------------------------------------- So if I understood you correctly, I should: Fork the master branch on GitHub, create a feature branch HHH-2770, implement it including tests and create a pull request afterwards. Correct? -- 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