Win a copy of The Little Book of Impediments (e-book only) this week in the Agile and Other Processes forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

High Performance Java Persistence: Spring JPA + Hibernate - Performance

 
Palak Mathur
Ranch Hand
Posts: 342
IntelliJ IDE Java Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Vlad,

I was just going through your book site the other day on recommendation of a friend of mine. I have not purchased it yet but the books seems promising. So, all the best.

Now coming to the topic. We use Spring Data + Hibernate as our Data Access layer. We create entity beans and use JPA Repository to query DB. This model works fine for small, single table queries. However, for complex, multi-table queries, it is quite cumbersome and slow. How would you recommend to handle this? I know one size doesn't necessarily fit all, but if you have to give a general guideline, what will it be?
 
Vlad Mihalcea
Author
Ranch Hand
Posts: 32
6
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I'm glad that you asked this question because I have been discussing this topic in the book as well.

Hibernate supports both fetching entities and DTOs, and that's been around for a long time now.
Fetching entities makes sense in two scenarios:

1. You want to update those entities in the current Persistence Context, or a future one (if you are in a web flow)
2. Your Domain Model is built out of independent entities which can mostly be navigated with @ManyToOne or @OneToOne associations, in which case the second-level cache can help you to fetch entities without hitting the DB.

But then, you might need complex lateral joins, CTE, window functions, and that's where native SQL shines.
Not only that you can get access to advance DB query capabilities, but you can tune the ResultSet to fetch just as much as your business case needs (unlike entity fetching which fetches all columns from a table row).

So, you should definitely use native queries for retrieving views, tables, infinite scrolls, etc.
 
Palak Mathur
Ranch Hand
Posts: 342
IntelliJ IDE Java Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thank you for your answer Vlad. That makes sense.

Recently, we are in process of eliminating all stored procedures and move them to Java layer. In the process, we have started exploring Hibernate Query Language(HQL). When you talk about Native queries, how efficient HQL is in comparison to them? Or not?
 
Tim Holloway
Saloon Keeper
Posts: 18367
56
Android Eclipse IDE Linux
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The reason that "NoSQL" DBMS's are so popular these days is because anything involving table joins is slower than single-table access. As for cumbersome, that's one of the things that JPA is supposed to be addressing. I certainly find it a lot easier to set up table relationships in Java code instead of having to code a lot of gnarly join statements.

The database EXPLAIN function is your friend. JPA's internal optimizers can do a lot, but there's nothing like a report straight from the database to tell you when a complex query is retrieving data the hard way so that you can know if/when/where to setup keys, foreign keys, indexes in general, and queries over large data sets that could have been pared back before the database had spent a lot of time on chewing through data that wasn't needed.
 
Vlad Mihalcea
Author
Ranch Hand
Posts: 32
6
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
If the stored procedures were used for OLTP, CRUD, or can be simply replaced by native SQL queries, then you should definitely replace them with Hibernate entity-state transitions and also natiev queries, which can be run from Hibernate too.

But if the stored procedures are used for processing data to avoid fetching tons of data over the network and do the processing in the application layer, then I think you should leave them as is.

Hibernate is suitable for OLTP, while stored procedures make sense in OLAP. Just because you are using Hibernate, it doesn't mean that the ORM tool is the only way to go.
Tou need to use what bets suits your data access requirements.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic