Member-only story
JDBC vs. JPA
In the land of software development, we sure love acronyms. Our acronyms in the land of Java-apps-talking-to-database, there is no shortage there.
And maybe this leads to confusion: What do I use? Everyone else is using JPA? Should I? But I heard about Spring Data JDBC? And what about Spring Data JPA?
In this article, we’ll talk about JDBC, JPA, where they came from, and the tradeoffs that exist.
Once, long ago, there was JDBC
JDBC is the Java Database Connectivity API. This is an old standard, going all the way back to the days of Java 1.1 in 1997. And this API has served us well.
Everything, and I mean EVERYTHING that talks to databases goes through JDBC. And that has its pros and cons. Basically, JDBC is the Java implementation of the standard dance ALL technologies have played to interact with databases.
- Open connection.
- Open cursor.
- Submit query.
- Iterate over result set.
- Close result set/cursor.
- Close connection.
And we’ve all probably suffered the fate of implementing twenty queries, and forgetting to CLOSE one of those resources along the way. And then, six weeks later, getting a scary stack trace because somehow our database has run out of connections or cursors.
We track down the issue. Patch it. Release it.
And then eight weeks later, we find another. This is what happens when we are on the hook for managing something that shouldn’t be that hard to manage.
And Spring saw this and took note. With one of its most popular and powerful coding patterns, Spring Framework release JdbcTemplate. A template that basically lets you focus on submitting queries and consuming the results.
All resource management was handled by the toolkit. Never again will you get a call at 3:00 AM because the database/your app has blown up.
Okay, maybe you still get those middle of the night calls. But not because you didn’t close a connection!
The thing is, once you’ve written two hundred queries, that amount of raw power capture in those strings becomes kind of…
