While Hibernate is a mature framework it still has a a lot of room for improvement. Starting from polishing documentation: e.g. “MappingException JavaDoc: An exception that usually occurs at configuration time, rather than runtime, as a result of something screwy in the O-R mappings.“, and going towards more powerful default optimization.
In fact, Rod Johnson (leader of Spring Framework’s parenthood gang :)), and other SpringSource consultants, constantly mention that most of their time, on projects that use Hibernate, is spent fixing Hibernate optimization bugs.
A lot of people form their opinions on what characteristics of “a good software framework” are. There are books, articles about it, but people are different, so opinions vary. One of the characteristics that makes a good framework, in my opinion is “while allowing clients to hook into the internal framework code, do not encourage it”. Meaning the flexibility is there, but the framework should not encourage its clients to get inside framework’s stereotypes. This way framework’s code (internal stereotypes) can alter, and still have “older version clients” running without (significant) change.
One of such hooks that Hibernate actually encourages to use is evicting the object from the session.
Here is an example:
While reviewing one of a Spring Batch jobs, I found that under the same “transaction management roof” (HibernateTransactionManager) jdbcTemplate and hibernateTemplate behaved differently: jdbcTemplate updated records in DB, but hibernateTemplate was not even trying.
So I enabled Hibernate logging in “log4j.properties”:
log4j.rootLogger = ERROR, errorsLog # Hibernate logs log4j.logger.org.hibernate = DEBUG, hibernateLog log4j.additivity.org.hibernate = false # HIBERNATE APPENDER log4j.appender.hibernateLog = org.apache.log4j.RollingFileAppender log4j.appender.hibernateLog.File = ./path-to/hibernate.log # Set the maximum log file size (use KB, MB or GB) log4j.appender.hibernateLog.MaxFileSize = 4096KB # Set the number of log files (0 means no backup files at all) log4j.appender.hibernateLog.MaxBackupIndex = 10 # Append to the end of the file or overwrites the file at start. log4j.appender.hibernateLog.Append = false log4j.appender.hibernateLog.layout = org.apache.log4j.PatternLayout log4j.appender.hibernateLog.layout.ConversionPattern = [%p] [%d{yyyy-MM-dd @ HH:mm:ss}] [%t|%c{1}] %m%n # ERRORS APPENDER log4j.appender.errorsLog = org.apache.log4j.RollingFileAppender log4j.appender.errorsLog.File = ./path-to/hibernate-error.log log4j.appender.errorsLog.MaxFileSize = 4096KB log4j.appender.errorsLog.MaxBackupIndex = 1 log4j.appender.errorsLog.layout = org.apache.log4j.PatternLayout log4j.appender.errorsLog.layout.ConversionPattern = [%p] [%d{yyyy-MM-dd @ HH:mm:ss}] [%t|%c{1}] %m%n |
First, I read an object via Hibernate, update it in the code, and then call a dao’s update method to persist it – pretty simple. However while debugging it step by step, after executing the Hibernate update query, in a log, I saw:
[DEBUG] [main|DefaultSaveOrUpdateEventListener] ignoring persistent instance [DEBUG] [main|DefaultSaveOrUpdateEventListener] object already associated with session: [EntityName#3] |
So the Hibernate did not update the object due the fact that it thought that another object was already associated with this Hibernate session. Which, in fact, was the same reference to the same object, only the update was called from a different instance.
The solution to this was to evict the object from the Hibernate session right after reading it:
ObjectDto objectDto = dao.findById( id ); dao.getHibernateTemplate().evict( objectDto ) |
Once the fix was applied, after Hibernate update call, I saw:
[DEBUG] [main|DefaultEvictEventListener] evicting [EntityName] [DEBUG] [main|DefaultSaveOrUpdateEventListener] updating detached instance [DEBUG] [main|DefaultSaveOrUpdateEventListener] updating [EntityName#3] [DEBUG] [main|DefaultSaveOrUpdateEventListener] updating [EntityName#3] |
And the object was successfully persisted into the database.
Happy ORMing!