The Hibernate team published the first Hibernate 5 release quite a while ago, and since then they introduced a bunch of new features. I explained several of them here on the blog, and it’s about time to have a look at the most popular ones. Based on the search traffic I get from google and my personal experience, the Java 8 support is the most popular change. But there are also some other features which might seem small but make common development tasks a bit easier.
Hibernate and JPA are so easy to use that you can learn the basics within 1 or 2 hours. But the problem starts as soon as you build an enterprise application. The number of users increases and you face challenging performance requirements.
That’s often the beginning of long hours of analyzing log files and asking questions on stack overflow.
But that doesn’t have to be the case.
Hibernate can easily handle the load and performance requirements of enterprise applications. I show you how to avoid some of them in this free video series.
You just have to subscribe below and I send you the first video.
Part 1: Find performance issues during development
Wouldn’t it be great to find Hibernate performance issues during development and not just after you deployed your change to production?
I was struggling with these issues for quite some time until I found out how Hibernate can tell me about potential performance issues. It requires just a small change to your development configuration. I show you what you need to do in this first video.
Part 2: Fix the most common performance issue
After you learned how to find Hibernate performance issues, you obviously have to fix them. I show you how to identify and fix the most common one in the 2nd video of this series.
Part 3: An overview about caching
In the 3rd video, I give you an overview about caching with Hibernate. Caching is an interesting topic and it can be a double-edged sword. Hibernate supports 3 different caches which can either provide huge performance benefits or an overhead that slows down your application.
In the final video, I tell you more about my Hibernate Performance Tuning Online Training and how it helps you to avoid performance issues.
Signup now to get this free video series
Storing the creation timestamp or the timestamp of the last update is a common requirement for modern applications. It sounds like a simple requirement, but for a huge application, you don’t want to set a new update timestamp in every use case that changes the entity.
You need a simple, fail-safe solution that automatically updates the timestamp for each and every change. As so often, there are multiple ways to achieve that:
- You can use a database update trigger that performs the change on a database level. Most DBAs will suggest this approach because it’s easy to implement on a database level. But Hibernate needs to perform an additional query to retrieve the generated values from the database.
- You can use an entity lifecycle event to update the timestamp attribute of the entity before Hibernate performs the update.
- You can use an additional framework, like Hibernate Envers, to write an audit log and get the update timestamp from there.
- You can use the Hibernate-specific @CreationTimestamp and @UpdateTimestamp annotations and let Hibernate trigger the required updates.
It’s obvious that the last option is the easiest one to implement if you can use Hibernate-specific features. So let’s have a more detailed look at it.
Hibernate 5.2 introduced several changes based on Java 8 features. In previous posts, I showed you how to get query results as a Stream and the support of DateTime API classes and Optional. In this post, I will have a look at a small change to some Hibernate annotations. Some of them are now @Repeatable which makes them much more comfortable to use.
Java 8 introduced Optional<T> as a container object which may contain null values. It’s often used to indicate to a caller that a value might be null and that it need to be handled to avoid NullPointerExceptions.
Sounds pretty useful, right?
So why not use them in your persistence layer for optional entity attributes or when loading entities that may or may not exist?
Until the release of Hibernate 5.2, the reason was pretty simple: It wasn’t supported. And you still have to wait for JPA 2.2 if you don’t want to rely on proprietary features. But that’s a different topic.
After they added support for the Java 8 DateTime API in Hibernate 5.0, the Hibernate team starts to use Java 8 Streams and Optional in their query APIs in Hibernate 5.2. In today’s post, I want to show you how you can use Optional<T> to indicate optional attributes and query results which might not return a result.