Hibernate anti-patterns and best practices – the server side java symposium

I was disappointed with this speaker’s previous session so I wasn’t sure whether to attend this one. I did like parts of this session better. It was interactive and presented alternate options. There was also a SQL/hsql puzzle to practice spotting errors. Similarly for java.

Transactional issues
Race condition if don’t have right transaction settings. Could solve with proper isolation level of serializable, but slows performance a lot. Repeatable read would not be ok because new row created in this example that not included in max so range query. Hibernate versioning also doesn’t help because on different table. Recommends reordering code so get Lock.UPGRADE first Note this is not a hibernate specific problem. The solution sounds like “for update” mode in Oracle. The speaker also noted an object should not be passing around internal state. Also not Hibernate specific, a query should be done in one step where possible.

other approaches:

  • track everything in Java, but then lose benefit of database
  • denormalize database
  • Use custom mappings with custom queries, laziness and order or where clause

Object oriented issues
Returning the raw list lets callers modify it, encapsulation matters, do not want inconsistent object state

To avoid

  • Write business methods before accessors
  • Hibernate can work with private, protected and package access
  • Date and Collections are the most likely causes of mutable internal state. Note that defensive copying requires retrieving all objects from thedatabase. Also Collections.unmodifiableList() is a problem because the dirty read check looks at the identity of objects.

Performance issues
There was some reuse in this section from the presenter’s other breakout.
Hibernate can be slow depending on usage. Having a getter return an unmodifiable list when cascade all is on, Hibernate deletes the whole collection and recreates if. The reason is that Hibernate sees the list as having a different identity. Thus can happen when calling get under certain conditions.

Automated detection
We got to hear content from the static analysis talk again. I didn’t like it any better this time because it is still vague.

Other things one could do wrong
Remember where clause criteria
Remember order of args in compareTo()

Conclusion – hibernate is hard, there will be a solution to make it easier one day

1 thought on “Hibernate anti-patterns and best practices – the server side java symposium

  1. Pingback: After The Server Side Java Symposium – live blog index | Down Home Country Coding With Scott Selikoff and Jeanne Boyarsky

Leave a Reply

Your email address will not be published.