• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Hibernate Performance Tuning Online Training

 
Ranch Hand
Posts: 572
2
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator


Hi,
What is the best way to avoid multiple sql queries being generated from a singe hibernate call ?

thanks,
Paul
 
Saloon Keeper
Posts: 27762
196
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I'm not sure what the question has to do with the subject line that it was posted under.

But my question is "why do you care how many SQL queries are coming from a single Hibernate call?"

As a general rule, the more complex the application is, the more efficient an ORM such as Hibernate can be even without manual tuning and especially at the SQL level.

I've seen benchmarks where an ORM gave double the throughput of manual JDBC calls, in fact.

It's never a good idea to prematurely optimize. Doing so usually doesn't help much because in real life, the bottlenecks measured almost never turn out where you "knew" they would be. In the mean time, the code has gotten more complex and harder to optimize where the real bottlenecks are.

I'd worry less about how many SQL statements are generated and more about how efficiently the ones that are generated run.
 
paul nisset
Ranch Hand
Posts: 572
2
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
The question was for a course being offered on Hibernate performance tuning.

My question is relevant to that.
The number of sql queries generated by a single hibernate query is relevant to Tuning Hibernate .
There are solutions .
In the case the solution is using a left join in your hibernate query on the column with the association.

I remember reading something similar to the article below and was interested in the author's thoughts on that.


http://www.javalobby.org/articles/hibernate-query-101/
 
Tim Holloway
Saloon Keeper
Posts: 27762
196
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I'm skeptical of the assertion that performance is solely determined on the mere number of SQL queries. A brute-force cross-product join is likely to have way more overhead than a series of more targeted individual queries, for example.

Ultimately, as I - and many others here - have said, the best optimization isn't based on what you "know", but on what you measure.
 
Author & Course Creator
Posts: 92
5
Hibernate Eclipse IDE Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
As others have already said, the number of SQL queries should not be the only thing you should worry about and you should not try to fix something that isn't broken. And always benchmark your application before and after your optimization.

The number of queries only becomes an issue, if there are a LOOOOOT of them like it can happen with eager fetching or the n+1 select issue. And even then you have to analyze if the join creates more harm or not.
So let's assume you have had:
The two most common reasons for additional queries are eager fetching and n+1 select issues.
The solution for eager fetching is simple, just switch it to lazy. But if you do that, you have to make sure that you don't create n+1 select issues, if Hibernate needs to initialize these relationships. You can avoid that by defining query specific eager fetching either with fetch joins

or by using EntityGraphs


You can check out my free mini-course, if you want to get into more details about finding n+1 select issues with Hibernate and fixing them with entity graphs.
 
paul nisset
Ranch Hand
Posts: 572
2
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Tim Holloway wrote:I'm skeptical of the assertion that performance is solely determined on the mere number of SQL queries.



You should be skeptical of that but I wasn't saying that was the sole measure of performance .
What I'm interested in is techniques for improving Hibernate performance so I have something to measure (the after).

As Thor mentioned,lazy loading of entities is probably going to have a bigger impact.


Thank you for mentioning the solution for the n+1 issue and EntityGraphs . EntityGraphs are not an area of Hibernate I was aware of or used.

 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
reply
    Bookmark Topic Watch Topic
  • New Topic