Spring JDBCTemplate VS Hibernate in terms of performance [closed]

Question

In our project we have to decide between Spring JDBCTemplate and Hibernate.

I want to know which is better in terms of performance and implementation and design. and how?

Pamphlet

Answer 1

If you do all you can to make both implementations very fast, the JDBC template will probably be a bit faster, because it doesn't have the overhead that Hibernate has. But it will probably take much more time and lines of code to implement.

Hibernate has its learning curve, and you have to understand what happens behind the scenes, when to use projections instead of returning entities, etc. But if you master it, you'll gain much time and have cleaner and simpler code than with a JDBC-based solution.

I would say that in 95% of the cases, Hibernate is fast enough, or even faster than non-optimized JDBC code. For the 5% left, nothing forbids you to use something else, like Spring-JDBC for example. Both solutions are not mutually exclusive.

Chinchin

Answer 2

That depends on your project and how well the Hibernate model fits the way you think. Speed/performance is irrelevant: If you can't wrap your mind about how Hibernate works, your project will be riddled with strange bugs that will take ages to find and fix.

Also note that the internals of Hibernate will leak into your model and DAOs. Notable points of conflict are usually equals()/hashCode() and lazy loading of collections outside of transactions. Since the examples with Hibernate are so simple and you can achieve a lot in a short time, this can lead to the misconception that Hibernate is simple. It's not. Hibernate makes a lot of assumptions and forces you to think and code in a certain way.

Using JdbcTemplate is easier because it's just a very thin wrapper around JDBC itself. The price here is that you will write thousands of lines of really boring code. Also, you will find that SQL strings are really hard to maintain. When your data model changes, you will have to search your whole code base for all places which might be affected. It won't be pretty.

For our own project, we decided against Hibernate because we have really complex data structures (revisioned tree structures) and have to build complex search queries at runtime. Instead, we wrote our own DAO layer using jOOQ. jOOQ is a thin wrapper around JDBC which allows you to write SQL with a nice DSL in Java:

create.selectFrom(BOOK)
      .where(PUBLISHED_IN.equal(2011))
      .orderBy(TITLE)

Like Hibernate, jOOQ has some rules which you should follow or you won't be happy but these are much more lenient.

As another option, you should have a look at Spring Data. In a nutshell, Spring Data allows you to store your data into anything that remotely resembles a database. This means you can manage your model with Hibernate and another using a NoSQL database. Or you can easily migrate part of your model as needed.

One of the key features is that the DAO implementation look like so:

public interface UserRepository extends Repository<User, Long> {

  List<User> findByEmailAddressAndLastname(String emailAddress, String lastname);
}

Now you may wonder where the implementation is since this is just an interface with a method definition but that's it. At runtime, Spring Data will generate code for you which implements this method. This is possible because 99% of all the queries which you will need are of the form "query table for all rows where column X is ..." so they optimized this use case.

OTOH, if you already know that you're going to build really complex search queries at runtime, Spring Data probably won't be of much help.

Laplace

so you can use spring data with mysql? I couldn't find a tutorial on that. – Convertiplane

Spring Data can wrap Hibernate and Hibernate can use MySQL. That would be one way to do it. But there might be other frameworks which support MySQL under the hood and Spring Data can also wrap. Your problem is that you start thinking from the database. Start thinking from the application; the underlying database is becoming invisible. – Laplace

I was hoping Spring Data JPA would be a Hibernate replacement for me, but I am actually not a fan. The custom interface solution in the documentation seems rather limiting. You are very correct that if you have many complex search queries at runtime, Spring Data is going to be very, very painful. I am still thinking good old Hibernate is the best if you don't care about vendor lock-in. – Tennilletennis

@egervari: Spring Data has other strengths, for example, you can mix Hibernate and NoSQL data sources (as long as you don't need joins, that is). Spring Data isn't a silver bullet. It just makes the common case more simple than Hibernate. If your project is 1% common cases, then it's not for you. If your project is 99% common cases, Spring Data becomes more simple than Hibernate. And it doesn't get in the way of the last 1% (unlike Hibernate). – Laplace

Answer 3

In our project, we are using both, JdbcTemplate and Hibernate. What you need to do is share DataSource between hibernate and jdbcTemplate. We can check performance for both according to operations, whichever is better, we use better one. Mostly we are using hibernate for normal operations, if there are big queries or heavy operations, we check performance for jdbc and hibernate whichever better we use it.

The good point is HibernateTransactionManager works for both (JdbcTemplate, plain jdbc) and hibernate.

Champagne

Don't you get problems with the caches? I.e. how do you refresh Hibernate cache, when you change tables by jdbcTemplate? Don't you get StaleStateExceptions? – Erythroblastosis

Answer 4

Is your database design hibernate friendly? If yes then use hibernate...if not then you may want to avoid it. Jdbctemplate has many upsides and there are ways to make sure your SQL queries are easily maintained. Have a class that holds all of them or read them from a file etc. If columns have to be update there is a way to use standard jdbc to get resultset meta data allowing you to retrieve column names. This can be complex but an interesting way to solve an issue. Hibernate is a great tool but complex data models make it get really tricky.

Apostate