Vlad Mihalcea

+ Follow
since Jan 27, 2016
Vlad Mihalcea is a Hibernate Developer Advocate working for Red Hat, passionate about concurrency challenges, high-performance enterprise solutions and online transaction processing.
He's been answering throusands of questions about Hibernate and JPA on StackOverflow for which he's got a Hibernate gold badge.
Whenever he finds something interesting, he likes to share it on his personal blog. He believes in Open Source Software and he thinks every developer should get involved, one way or the other.
If he doesn’t find a suitable tool for a job, he takes initiative and starts a new open source project, like FlexyPool.
Cows and Likes
Total received
In last 30 days
Total given
Total received
Received in last 30 days
Total given
Given in last 30 days
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Vlad Mihalcea

Check out this article.

I contains a great deal of examples that you can use to call an Oracle stored procedure or function from Hibernate ORM.
Hi Jeff,

Thanks for writing this book. Does the book cover only Docker, or do you write about Kubernetes as well?

6 years ago
The new Hibernate User Guide is very good for learning Hibernate, but, if you want to learn how to squeeze the last performance drop out of your data access layer, you might want to read the High-Performance Java Persistence book as well.
Thanks for hosting this event and congratulations to the lucky winners.
I'm looking forward to getting your feedback.
Probably they wanted you to say that JTA is needed because each airline can be considered as a different Resource Adapter while you have a single global transaction.

I have two more chapters for the second part: Caching and Concurrency Control, and then a short part on jOOQ.
I'm not sure how much that will take because it implies doing some corrections after I get more reviews.
The good thing about Leanpub is that you can get the book know and get any update for free.

The book is not focused on Spring because the actual tuning happens in Hibernate, JDBC, and the DB part.
Related to testing, there is going to be an article on my blog next week, so better subscribe to my newsletter.

Using simple associations, using DTO projections for views, the enhances identifiers, batching, caching, there are many things you can optimize you Hibernate data access layer.
I use DataSource-proxy for logging statements because it allows me to add custom listeners like to ensure the statement count is the one I expect it to be.
You can always call stored procedures from JDBC too. It's not as elegant, but if it works, why not.
Thanks, Ramya.

Hibernate uses PreparedStatements for every SQL statement that is executed, so, as long as you don't concatenate SQL strings, you should be fine with JPQL, Criteria API, and native queries too.

I find JPQL much more expressive than Criteria API. However, Criteria API is the right tool for building dynamic entity queries programmatically and in a type-safe way.
This way, JPQL and Criteria API are complementary, not competing one against each other.
Criteria API creates more objects that JPQL, so the performance penalty comes only from more work being done by GC.

JPA 2.1 allows you to call stored procedure, check out this article that I wrote, and ParameterMode supports IN, OUT, INOUT and REF_CURSOR too.

It surely helps. The first part is about JDBC which you are using implicitly so every tip I gave applies to any Java application connection to a RDBMS.
The second part, even if about Hibernate, it explains various performance optimizations that other providers might also offer too.
After you read the whole book, you'll know what to look after in any data access framework you'd be using from there after.
Unfortunately, jTDS hasn't moved forward, being stuck with JDBC 3.0. The Microsoft driver has released new versions in the meanwhile, so, it might be the only option these days.
If premature optimization is a bad thing, designing the data access layer without knowing the stack underneaths is even worse.

An ORM tool can make it very easy to select way too much data or to execute more queries than necessary.
Many performance issues don't arise during development phase due to lack of data, and once you move into production and data accumulates, the problems start to become obvious.
That's, unfortunately, a way to common scenario too.

Monitoring and measuring is the most reliable way to find the cause of any given performance issue, and doing it incrementally while the project is still under development can give a better understanding of how the stack behaves when a traffic spike occurs or when the underlying data keeps on increasing.
I always try to understand the JDBC driver as much as possible and also get familiar with the bugs as well.
After all, every statement flows through the driver, and if it has an issue, there isn't much you can do in an upper-layer such as Hibernate.

The first part of my book dives into Oracle, SQL Server, PostgreSQL, and MySQL driver peculiarities in relation to batching, statement caching, fetching particularities, and also concurrency control on the db side.
As a back-end developer, we are supposed to know how the database works, how to index it, how to interpret an execution plan, to write the most effective queries.
This means we need to be very familiar with the database manual and also the JDBC driver documentation.