This is an absolute goldmine, thanks Maciej!!! We have a part of our application that takes about 40ms to do a simple insert so this talk is excellently timed 👌🏻
Awesome talk, Maciej. One can not emphasis enough the importance of understanding what's going on behind Hibernate & Spring Data JPA - I really liked the wallpaper 🍃
Hi Everyone, I have one issue. Can someone please check and let me know what might be the problem. I have one sql retrieval query on VIEW, which has large data with some joins and unions. Now when I execute the plain sql query in sql developer it took 250 ms. And I have tried same SQL query hardcoded values in @Query, it took around 320 ms. But when I make that sql query parameterized using @Query and @Param, it’s taking around 32 seconds. Can someone tell me what is happening here? Sorry for unable to share the sql and code details. Thanks in advance 👍🏻
Hello and thank you for the great presentation. I guess everyone learned something from watching this talk. I just have one question towards the end of the talk we could combine JPA specifications With fetching projections dynamic so that way we can also pass dynamic condition to our dynamic projection?
Great talk. Personally I think this is not fully applicable to to cloud like installations where db might be remote and having short but many session may give opposite effect as cost of interacion multiply by hundreds may lead to significant delay in app response time. I have seen such case recently.
I have a question in bank transfer execute method he said hibernate will open the session then closes in case of findById.But earlier he said because of OSIV it mantains a session throughout request after a db call. can anyone answer
Because we have already assigned ids for these entities, and thus save() method will underneath invoke merge() instead of persist() and merge underneath has to check if these entities exists, so it has to issue another select query. In case when you are using @Transactional, the entities from the first and second select will be stored in hibernate session cache and thus the merge, instead of firing new request, can simply take it from cache.
If anyone doesn't understand jpa and hibernate at this level(internal workings), they will screw up the application. I think it's better to write plain SQL queries and execute or may be JOOQ helpful.
Is there any reason you did not fix the aggregate model instead? It's a phenomenon I run into quite frequently: folks run into performance problems and immediately resort to tweaking persistence metadata, when *actually* the problem is in the model itself. Spring Data deals with DDD aggregates, in which Many-to-One relationships to other aggregates have no place at all. Those would be modeled as identifier references instead, so that these are basic values to Hibernate, and it would not need to resolve references The entire lazy/eager discussion is avoided on the Hibernate level. No get-by-reference tricks, no tweaking of Hibernate metadata. Applications would simply resolve the identifiers when they *actually* need the reference. Creating a BankTransfer wouldn't even need to resolve the accounts beforehand.
Using hibernate for 5 years, I agree that it is not the best tool for database handling. Most of the time plain SQL is much more predictable and easy to work with
Simple answer is dont use Hibernate, It makes simple problem more simpler (which we might not need) and complex problem more complex (which we definatly not need it), Got for micro framework like MyBatis if you really want to consider performance, its great sweet point.
Great talk and thanks for the shout out!
you look familiar
Of course you were mentioned in the first five minutes :D.
@@frostbittenkingdoms245 Who would have thought? :D
This is an absolute goldmine, thanks Maciej!!! We have a part of our application that takes about 40ms to do a simple insert so this talk is excellently timed 👌🏻
learned many things, enjoyed every second of the talk
This was exceptionally useful, thanks mr. Walkowiak
Thanks for sharing. More sessions like this please!
Awesome talk, Maciej. One can not emphasis enough the importance of understanding what's going on behind Hibernate & Spring Data JPA - I really liked the wallpaper 🍃
This is actually a good talk, applicable across several languages
I once attended one of Vlad's lectures at the JAX and i had the feeling (same as here) that the time is over, when it is getting interesting.
Definitely need to try PROJECTIONS ...
Pure gold! Thank you so much for the awesome presentation.
Very very good talk, hands on and i took away at least 4 things that i did not know or did not fully understand before. Thanks!
As a Java beginner, this talk made me want to steer clear of JPA.
is this video about using Flexy Pool for database connection pooling ???
Thanks for the mention:) We appreciate it!
at 21:49 can anyone help me explain why Hibernate logs appeared before Flexypool's logs? thanks in advance 🙇🏻
Good talk, thank you Maciej
Hi Everyone, I have one issue. Can someone please check and let me know what might be the problem.
I have one sql retrieval query on VIEW, which has large data with some joins and unions. Now when I execute the plain sql query in sql developer it took 250 ms. And I have tried same SQL query hardcoded values in @Query, it took around 320 ms.
But when I make that sql query parameterized using @Query and @Param, it’s taking around 32 seconds.
Can someone tell me what is happening here? Sorry for unable to share the sql and code details.
Thanks in advance 👍🏻
Hello and thank you for the great presentation. I guess everyone learned something from watching this talk.
I just have one question towards the end of the talk we could combine JPA specifications With fetching projections dynamic so that way we can also pass dynamic condition to our dynamic projection?
Very very good talk. I enjoyed it
Great talk. Personally I think this is not fully applicable to to cloud like installations where db might be remote and having short but many session may give opposite effect as cost of interacion multiply by hundreds may lead to significant delay in app response time. I have seen such case recently.
34:34 "It's a commercial tool, which is great.. for Vlad" ROTFL!! 🤣🤣🤣
I have a question in bank transfer execute method he said hibernate will open the session then closes in case of findById.But earlier he said because of OSIV it mantains a session throughout request after a db call. can anyone answer
27:20 I didn't understand how annotating the execute() method with @Transactional reduced the number of database queries. Can someone explain pls?
Because we have already assigned ids for these entities, and thus save() method will underneath invoke merge() instead of persist() and merge underneath has to check if these entities exists, so it has to issue another select query. In case when you are using @Transactional, the entities from the first and second select will be stored in hibernate session cache and thus the merge, instead of firing new request, can simply take it from cache.
thank you for this amazing talk
Vlad actually used to work on the Hibernate project for RedHat in the past at some point.
Awesome talk, thanks!🎉
This was exceptional. Thanks
it was really helpful. thank you for your hard work
Thanks so much for this video. It helped me a lot. Thanks.
Great Talk Man !!
If anyone doesn't understand jpa and hibernate at this level(internal workings), they will screw up the application. I think it's better to write plain SQL queries and execute or may be JOOQ helpful.
Thanks, do you have any simple spring boot starter for Jooq for and intermediate level experience with jdbc and pure sql
@@rajeshhazari i didn't understand your question, you need code samples for JOOQ ?
@@praveens2272 yes some samples starters using jooq to show complex examples
I tried open-in-view -> false, and the applications feels 30% slower now.
Nice video!
Golden ❤
Is there any reason you did not fix the aggregate model instead? It's a phenomenon I run into quite frequently: folks run into performance problems and immediately resort to tweaking persistence metadata, when *actually* the problem is in the model itself.
Spring Data deals with DDD aggregates, in which Many-to-One relationships to other aggregates have no place at all. Those would be modeled as identifier references instead, so that these are basic values to Hibernate, and it would not need to resolve references The entire lazy/eager discussion is avoided on the Hibernate level. No get-by-reference tricks, no tweaking of Hibernate metadata. Applications would simply resolve the identifiers when they *actually* need the reference. Creating a BankTransfer wouldn't even need to resolve the accounts beforehand.
This demo code is available in GitHub? If not please share the link. Thanks.
Gib code pls 😂
It's there on his GitHub page. Repo name: performance-oriented-spring-data-jpa-talk
Using hibernate for 5 years, I agree that it is not the best tool for database handling. Most of the time plain SQL is much more predictable and easy to work with
First YAGNI Spring
Simple answer is dont use Hibernate, It makes simple problem more simpler (which we might not need) and complex problem more complex (which we definatly not need it), Got for micro framework like MyBatis if you really want to consider performance, its great sweet point.
cant even lazy load one to one
Do you have a long running transaction? just split it into two transactions 😂
Shields Mountain
Or use SQL and clojure with it's awesome data strucutres :)
spring is slow java is fastt
Projections with nested entities are sucks ...
This is great to know and think about, thanks