Hibernate Performance Best Practice?

Question

Im writing a Web application using Hibernate 3.

So, after a while i noticed that something was slow. So i tested hibernate profiler and found that hibernate will make unreasonably many db-calls for simple operation. The reason is ofcourse that i load an Object (this object has several "parents") and these "parents" have other "parents". So basicly hibernate loads them all, even though i just need the basic object. Ok, so i looked into lazy-loading. Which lead me into the Lazyloading-exception, because i have a MVC webapp.

So now i'm a bit confused as to what is my best approach to this. Basicly all I need is to update a single field on an object. I already have the object-key.

Should I: 1. Dig into Lazy-loading. And then rewrite my app for a open-session-view? 2. Dig into lazy-loading. And then rewrite my dao's to be more specific. E.g. writing DAO-methods that will return objects instanciated with only whats necessary for each use-case? Could be a lot of extra methods... 3. Scratch hibernate and do it myself? 4. Cant really think of other solutions right now. Any suggestions?

What is the best practice?

Answer 1

• Don't use joins unless really needed. They won't allow you to use neither lazy loading, nor using 2nd level cache for associations
• Use lazy="extra" for large collections, it won't retrieve all the elements until you ask it, you can also use size() method for instance without getting elements from DB

• Use load() method if it's possible since it doesn't issue a select query until it's required. E.g. if you have a Book and an Author and you want to associate them together, this will won't issue any selects, only single insert:

  Book b = (Book) session.load(Book.class, bookId);
  Author a = (Author) session.load(Author.class, authorId);
  b.setAuthor(a);
  session.save(b);
  

• Use named queries (in your hbm files or in @NamedQuery) so that they are not parsed during each query. Don't use Criteria API until it's required (it makes impossible to use PreparedStatement cache in this case)

• Use OSIV in your web app since it will load data only when/if it's needed
• Use read-only modes for selects-only: session.setReadOnly(object, true). This will make Hibernate not to keep an original snapshot of the selected entity in the persistent context for further dirty checks.
• User 2nd level cache and Query Cache for read-mostly and read-only data.
• Use FlushMode.COMMIT instead of AUTO so that Hibernate doesn't issue select before updates, but be ready that this may lead to stale data being written (though Optimistic Locking can help you out).
• Take a look at batch fetching (batch-size) in order to select several entities/collections at one time instead of issuing separate queries for each one.
• Do queries like 'select new Entity(id, someField) from Entity' in order to retrieve only required fields. Take a look at result transformers.
• Use batch operations (like delete) if needed
• If you use native queries, specify explicitly what cache regions should be invalidated (by default - all).
• Take a look at materialized path and nested sets for tree-like structures.
• Set c3p0.max_statements in order to enable PreparedStatment cache in the pool and enable the statement cache of your DB if it's switched off by default.
• Use StatelessSession if it's possible, it overcomes dirty checks, cascading, interceptors, etc.
• Do not use pagination (setMaxResults(), setFirstResult()) along with queries that contain joins to collections, this will result in all the records pulled from database and pagination will happen in memory by Hibernate. If you want pagination, ideally you shouldn't use joins. If you can't escape it, again - use batch fetching.

Actually there are a lot of tricks, but I can't recall more at the moment.