My Quotes

When U were born , you cried and the world rejoiced
Live U'r life in such a way that when you go

Thursday, May 5, 2016

Hibernate best practices

  1. Prefer crawling the object model over running queries
    • Querying in hibernate always causes a flush
  2. Make everying lazy
    • First read will be slow but everything else will be cached
  3. Use second level cache
  4. Use cascade cautiously
    • Hibernate is not good at saving a whole object tree in one go
  5. Use Field access over method access
    • will be faster since no relfection is used
  6. Use instrumentation
  7. Don't use auto generated Keys
    • you have to wait until the object is persisted before its equals method works
  8. Use id based Equality
  9. Write fine-grained classes and map them using .
    • Use an Address class to encapsulate street, suburb, state, postcode. This encourages code reuse and simplifies refactoring.
  10. Declare identifier properties on persistent classes.
    • Hibernate makes identifier properties optional. There are all sorts of reasons why you should use them. We recommend that identifiers be 'synthetic' (generated, with no business meaning) and of a non-primitive type. For maximum flexibility, use java.lang.Long or java.lang.String.
  11. Place each class mapping in its own file.
    • Don't use a single monolithic mapping document. Map in the file com/eg/Foo.hbm.xml. This makes particularly good sense in a team environment.
  12. Load mappings as resources.
    • Deploy the mappings along with the classes they map.
  13. Consider externalising query strings.
    • Externalising the query strings to mapping files will make the application more portable.
  14. Use bind variables.
    • Even better, consider using named parameters in queries.
  15. Don't manage your own JDBC connections.
    • Hibernate lets the application manage JDBC connections. This approach should be considered a last-resort.
    • If you can't use the built-in connections providers, consider providing your own implementation of net.sf.hibernate.connection.ConnectionProvider.
  16. Consider using a custom type.
    • Suppose you have a Java type, say from some library, that needs to be persisted but doesn't provide the accessors needed to map it as a component.
    • You should consider implementing net.sf.hibernate.UserType.
    • This approach frees the application code from implementing transformations to / from a Hibernate type.
  17. Understand Session flushing.
    • From time to time the Session synchronizes its persistent state with the database.
    • Performance will be affected if this process occurs too often.
    • You may sometimes minimize unnecessary flushing by disabling automatic flushing or even by changing the order of queries and other operations
      within a particular transaction.
  18. In a three tiered architecture, consider using saveOrUpdate().
    • When using a servlet / session bean architecture, you could pass persistent objects loaded in the session bean to and from the servlet / JSP layer.
    • Use a new session to service each request. Use Session.update() or Session.saveOrUpdate() to update the persistent state of an object.
  19. In a two tiered architecture, consider using session disconnection.
    • Database Transactions have to be as short as possible for best scalability.
    • This Application Transaction might span several client requests and response cycles.
    • Either use Detached Objects or, in two tiered architectures, simply disconnect the Hibernate Session from the JDBC connection and reconnect
      it for each subsequent request.
    • Never use a single Session for more than one Application Transaction usecase, otherwise, you will run into stale data.
  20. Don't treat exceptions as recoverable.
    • This is more of a necessary practice than a "best" practice.
    • When an exception occurs, roll back the Transaction and close the Session.
    • If you don't, Hibernate can't guarantee that in-memory state accurately represents persistent state.
    • As a special case of this, do not use Session.load() to determine if an instance with the given identifier exists on the database;
    • use find() instead.
  21. Prefer lazy fetching for associations.
    • Use eager (outer-join) fetching sparingly.
    • Use proxies and/or lazy collections for most associations to classes that are not cached at the JVM-level.
    • For associations to cached classes, where there is a high probability of a cache hit, explicitly disable eager fetching using outer-join="false".
    • When an outer-join fetch is appropriate to a particular use case, use a query with a left join fetch.
  22. Consider abstracting your business logic from Hibernate.
    • Hide (Hibernate) data-access code behind an interface.
    • Combine the DAO and Thread Local Session patterns.
    • You can even have some classes persisted by handcoded JDBC, associated to Hibernate via a UserType.
  23. Implement equals() and hashCode() using a unique business key.
    • If you compare objects outside of the Session scope, you have to implement equals() and hashCode().
    • If you implement these methods, never ever use the database identifier!
    • To implement equals() and hashCode(), use a unique business key, that is, compare a unique combination of class properties.
    • Never use collections in the equals() comparison (lazy loading) and be careful with other associated classes that might be proxied.
  24. Don't use exotic association mappings.
    • Good usecases for a real many-to-many associations are rare.
    • Most of the time you need additional information stored in the "link table".
    • In this case, it is much better to use two one-to-many associations to an intermediate link class.
    • In fact, we think that most associations are one-to-many and many-to-one, you should be careful when using any other
    • association style and ask yourself if it is really neccessary.

No comments :