Red Hat

In Relation To

The Hibernate team blog on everything data.

We just published 5.8.0.Final, the first stable release in the 5.8 branch. Hibernate Search is now compatible with every recent, stable versions of Elasticsearch!

What’s new?

Here are the most notable changes since Hibernate Search 5.7:

And much more! For a full list of changes since 5.7, please see this list of tickets on our JIRA instance.

For those of you keeping track of the Alpha/Beta/CR releases: the candidate release phase went rather well, with only a few bugs fixed since CR1. For a full list of changes since 5.8.0.CR1, please see the release notes.

How to get these releases

All versions are available on Hibernate Search’s web site.

Ideally use a tool to fetch it from Maven Central; these are the coordinates:


To use the experimental Elasticsearch integration you’ll also need:


To use Amazon’s proprietary IAM authentication mechanism to access your Elasticsearch cluster you’ll also need:


Downloads from Sourceforge are available as well.

Feedback, issues, ideas?

To get in touch, use the following channels:

Hibernate ORM 5.2.11.Final released

Posted by    |       |    Tagged as Hibernate ORM Releases


For information on consuming the release via your favorite dependency-management-capable build tool, see

Changes to how Clob values are processed using PostgreSQL81Dialect and its subclasses

A breaking change was made in how Clob values are processed using PostgreSQL81Dialect and its subclasses. The following is copied from the migration guide.

Up to and including 5.2.8, Clob values and values for String, character[], and Character[] attributes that are annotated with @Lob were:

  • bound using Clob representations of the data (using PreparedStatement#setClob or CallableStatement#setClob);

  • retrieved as Clob values (using ResultSet#getClob or CallableStatement#getClob), which were converted to the appropriate Java type;

  • stored as PostgreSQL Large Objects; i.e., an OID for the value is stored in a text column, which refers to the actual data stored in a different (PostgreSQL-specific) table.

In 5.2.9 and 5.2.10, due to the fix for HHH-11477, Clob values and values for String, character[], and Character[] attributes that are annotated with @Lob were:

  • bound using String representations of the data (using PreparedStatement#setString or CallableStatement#setString);

  • retrieved as String values (using ResultSet#getString or CallableStatement#getString), which were converted to the appropriate Java type;

  • stored as variable-length character strings.

In 5.2.11, the fix for HHH-11477 was reverted (HHH-11614) to restore the 5.2.8 behavior.

As a consequence of these changes, data persisted using a version of Hibernate prior to 5.2.9 cannot be read using 5.2.9 or 5.2.10. Data persisted using Hibernate 5.2.9 or 5.2.10 can no longer be read using 5.2.11 or later.

A workaround that can be used in 5.2.9 and 5.2.10 that will restore the 5.2.8/5.2.11 behavior is to override the PostgreSQL dialect with:

public SqlTypeDescriptor getSqlTypeDescriptorOverride(int sqlCode) {
        if( sqlCode == Types.CLOB ){
                return ClobTypeDescriptor.CLOB_BINDING;
        return super.getSqlTypeDescriptorOverride( sqlCode );

In addition, any Clob values and values for String, character[], Character[] attributes that are annotated with @Lob that were stored as variable-length character strings using 5.2.9 or 5.2.10 should be updated to store the values as PostgreSQL Large Objects before migrating to 5.2.11.

For example, if variable-length character strings were stored by 5.2.9 or 5.2.10 for the following mapping:

@Entity(name = "TestEntity")
@Table(name = "TEST_ENTITY")
public static class TestEntity {
        private long id;

        String firstLobField;

        String secondLobField;

        Clob clobField;


the variable-length character strings can be converted to PostgreSQL Large Objects by executing the following SQL:

update test_entity
set clobfield = lo_from_bytea( 0, cast( clobfield as bytea ) ),
    firstlobfield = lo_from_bytea( 0, cast( firstlobfield as bytea ) ),
    secondlobfield = lo_from_bytea( 0, cast( secondlobfield as bytea ) )

Welcome to the Hibernate community newsletter in which we share blog posts, forum, and StackOverflow questions that are especially relevant to our users.


Don’t miss our Hibernate developer interviews with Arnold Gálovics and Jakub Kubryński.

If you want to share your story about Hibernate, let us know, and we can share it with our huge community of passionate developers.


I released a training video about the best way to log SQL statements with JDBC and Hibernate.

If you liked it, then don' forget to subscribe to my YouTube channel. I’ll release a new video every week, so stay tuned for more.


The pick of this Newsletter is this article by Randall Hyde from 2009 about the Fallacy of Premature Optimization. Way too often, performance is not considered from the very beginning when designing an enterprise application, and neglecting performance can have a serious impact when the application is launched into production.

Reading database Execution Plans is not a trivial thing to do. This article takes a different approach and tries to explain various algorithms employed by an Execution Plan using Java and C++ code examples.

While fetching entities is suitable when you plan to modify them, DTO projections are more convenient when for read-only transactions. Check out this article about the best way you can map a DTO projection using JPA and Hibernate.

If you’re using Spring Data JPA and want to use an automatic schema migration tool like Liquibase, then you should definitely read this step-by-step tutorial.

Whenever you find yourself self-joining two tables to correlate aggregate functions with the original table rows, you are better off using a Window Function. This article gives you two solutions to a given SQL problem: one with Window Functions and one without them. Not only that the Window Function query is more expressive, but it’s more efficient as well.

If you want to learn the difference between save, persist, merge, and saveOrUpdate, this article offers a very good introduction on this topic. While at it, there’s also a performance impact related to merge when doing batch processing. Luckily, the Hibernate-specific update method is there to help you tackle this issue.

Hibernate is extremely flexible. For instance, you can even use a Composite Identifier where one of the columns uses a @GeneratedValue directive. This is probably one of the few use cases where the JPA @IdClass construct actually makes sense.

Hibernate OGM 5.2 Alpha1 is out

Posted by    |       |    Tagged as Hibernate OGM Releases

I’m happy to announce the latest release of Hibernate OGM: Hibernate OGM 5.2 Alpha1

The first thing you will notice in this release is that several dialects are not part of the core project anymore. We decided to focus our work on the Infinispan, Neo4j and MongoDB dialects.

Highlights of the release:

If you need to upgrade from a version before 5.2, you can find help on the migration notes.

All the changes are described in the release notes.

What happened to the CouchDB, Redis, Cassandra and Ehcache dialects?

They have now their own repository:

Keeping too many dialects aligned in term of features and releases is starting to impact the speed of our development. We decided to focus our attention on the most popular dialects and, at the same time, give contributors the freedom to manage the dialect without having to wait for us.

From now on, a new dialect will spend some time in its own repository and it will be included in the core project only if we consider it mature enough and, ideally, if somebody volunteers to maintain it regularly.

This also means that in the future we might not release all these dialects for each hibernate-ogm-core release.

Feel free to contact us if you have more questions about this.

Where can I get it?

You can get the required core library using the following Maven coordinates:

  • org.hibernate.ogm:hibernate-ogm-core:5.2.0.Alpha1

and these are the backends currently available for 5.2.0.Alpha1:

  • Cassandra: org.hibernate.ogm:hibernate-ogm-cassandra:5.2.0.Alpha1

  • CouchDB: org.hibernate.ogm:hibernate-ogm-couchdb:5.2.0.Alpha1

  • Infinispan

    • Embedded: org.hibernate.ogm:hibernate-ogm-infinispan:5.2.0.Alpha1

    • Remote: org.hibernate.ogm:hibernate-ogm-infinispan-remote:5.2.0.Alpha1

  • Ehcache: org.hibernate.ogm:hibernate-ogm-ehcache:5.2.0.Alpha1

  • MongoDB: org.hibernate.ogm:hibernate-ogm-mongodb:5.2.0.Alpha1

  • Neo4j: org.hibernate.ogm:hibernate-ogm-neo4j:5.2.0.Alpha1

  • Redis: org.hibernate.ogm:hibernate-ogm-redis:5.2.0.Alpha1

Alternatively, you can download archives containing all the binaries, source code and documentation from Sourceforge.

What’s next?

Our work will focus mainly on the Infinispan Remote dialect and the upgrade to Hibernate ORM 5.2.

Special thanks

I would like to thanks some contributors that helped us adding new features and fix some unexpected behaviours:

  • Hubert Holierhoek for finding ways to make the queries on Neo4j faster

  • Raghav Jha thanks to him MongoDB native queries now support Map-Reduce and distinct operations

  • Sergey Chernolyas for helping with the MongoDB dialect and the work on the OrientDB and Apache Ignite dialects (coming soon)

  • Dimitrij Drus for helping us finding some problems with polymorphic hierarchies (now fixed)

How can I get in touch?

You can find us through the following channels:

We are looking forward to hearing your feedback!

Meet Jakub Kubryński

Posted by    |       |    Tagged as Discussions Hibernate ORM Interview

In this post, I’d like you to meet Jakub Kubryński, a software developer, blogger, conference speaker, and Java Persistence aficionado.

Jakub Kubryński, align=

Hi, Jakub. Would you like to introduce yourself and tell us a little bit about your developer experience?

Thank you very much for inviting me here. My name is Jakub Kubryński (@jkubrynski on Twitter).

I live in Poland. I’ve been playing with programming since I was 7 years old.

My first language was Fortran 77, which was introduced to me by my dad, who is a researcher in aerodynamics. In 2004, I started my first regular job as a software developer, and since then I’ve stayed involved in this industry.

My career path has gone through Junior Developer to Architect, Team Leader, Development Manager and Trainer.

For the last 5 years, I’ve been working for my own company, Devskiller, where we’ve created a tool for testing technical skills of professional software developers and DevOps engineers, including practical knowledge of tools, libraries, and frameworks.

I liked your JPA Beyond copy-paste presentation. What did you decide to cover this topic in a conference presentation?

Apart from my main job at Devskiller, I try to give back some of my experience by training other developers.

During my professional career, I’ve already trained around 700 developers. Among other subjects, I give many trainings related to Java performance and JPA.

During those trainings, I’ve realized that many developers have problems with similar things. Those things are extremely important when working with JPA, so why not cover them in a conference talk to help more people than I can do during my trainings.

How many conferences did you give this presentation and what was the audience reaction upon unraveling so many tips about JPA and Hibernate performance?

As we all know, the Golden Hammer does not exist. While Hibernate is still the most popular persistence technology in Java ecosystem, we shouldn’t limit ourselves to just one technology.

There are libraries such as jOOQ, which is a great addition to JPA for implementing CQRS (Command Query Responsibility Segregation) based systems (JPA for commands and jOOQ for queries).

We also, pretty often, decide to migrate the read model to non-relational databases like MongoDB.

I’m also curious how NewSQL databases (based on Google Spanner white paper) will change the situation. The goal is to get relational databases with performance and scalability similar to those of NoSQL engines.

Since NewSQL is still SQL-driven, we could probably get Hibernate to be their default interface to the Java world.

The biggest problem is that developers are trusting Hibernate so much that they don’t even check what queries are executed under the hood. In fact, both mappings and JPQL queries can be improved a lot by changing just a few lines of code like, for example, replacing java.util.List with java.util.Set, removing joining tables or adding fetch joins into queries.

There is also some serious incomprehension of the level-one cache behavior, which is especially important when doing batch processing.

Last but definitely not least, the problem is related to the Open Session in View anti-pattern. Allowing developers to ignore transactional boundaries can lead to serious performance issues after releasing the product into production.

We always value feedback from our users, so can you tell us what you’d like us to improve or are there features that we should add support for?

At first, I want to congratulate you. Hibernate is one of the oldest (or the oldest?) and still alive open-source project related to Enterprise Java.

I think the moment you’ve joined the core team refreshed the spirit. I hope you’ll continue working on making Hibernate simpler for newbies - even just by discovering and logging common bad practices related to modeling entities.

Thank you, Jakub, for taking your time. It is a great honor to have you here. To reach Jakub, you can follow him on Twitter.

Meet Arnold Gálovics

Posted by    |       |    Tagged as Discussions Hibernate ORM Interview

In this post, I’d like you to meet Arnold Gálovics, a software developer, blogger, and Java Persistence aficionado.

Arnold Gálovics, align=

Hi, Arnold. Would you like to introduce yourself and tell us a little bit about your developer experience?

Hi, Vlad. First of all, I’d like to thank you for having me. My name is Arnold Gálovics (@ArnoldGalovics on Twitter). I’m 25 years old and currently living in the capital of Hungary, Budapest.

Since I got my first computer, I’ve always been curious how software works, so I got into the software development industry to see what’s happening under the hood.

In the last 5 years, I worked in the telecommunication industry where I was responsible for developing an application for strictly internal usage which was purely just getting and manipulating the data we needed and at the end wiring it together.

After that, I got into the financial industry and now I’m working on a very interesting project where we are creating a huge platform with all the new fancy tools/technologies.

In the last few years, I was mostly focusing on the standard Java stack, Oracle, JPA/Hibernate, Spring, Eclipse RCP, Angular. First, when I got into the JPA world, it was like real magic for me what was happening and how clever the people are who wrote such a tool. A couple of months ago I wanted to try myself out in the open-source community, and I chose Hibernate ORM to contribute into as it was familiar to me and, of course, I wanted to give something back.

In the meantime, I also started a technical blog where I love to publish articles. Despite the fact, I don’t have the time I’d like to invest into blogging because I’m currently working as a Senior Software Engineer in a full-time job, but I’m trying to work on it as much as I can.

You wrote several articles about JPA and Hibernate on your blog. In your experience, is it JPA and Hibernate a valid option for a typical Java EE application?

Absolutely. Especially for smaller projects but of course it’s reliable for bigger ones as well you just have to understand the consequences of the choices you make. In good hands, for a relational database, Hibernate is a really great choice.

There are tons of great features which are helping you throughout the evolution of the application, and I strongly feel that especially lately the Hibernate team did an amazing job for making the ORM framework better and better.

As I mentioned, there are lots of great features offered by Hibernate, but people often think that Hibernate is a silver bullet and they usually don’t understand the concept or how a certain feature should be used.

The main problem is that people tend to forget that under JPA/Hibernate, there are SQL statements executed against the underlying database and they don’t care about this, thus struggling with the performance of the application.

There are simple things which you should look out for, like the merge pitfall of declarative transaction management, entity state transitions, fetching only the data you need, etc.

I’ve seen many projects which are using anti-patterns in the data-access layer like putting every association to EAGER fetching, having a general data-access layer, wrong transaction boundaries.

Usually, after a couple of performance issues, projects want to drop JPA/Hibernate just to go with pure SQL to have better performance, however, understanding the problem and verifying the executed SQL statements is the way to go in my opinion instead of dropping the ORM completely.

My main message here is: you can use JPA/Hibernate for your project, just understand how it works and how to use it efficiently. There are books, blogs, the user guide improved a lot.

I personally recommend reading Vlad’s High-Performance Java Persistence book and his blog because you can learn a lot from it.

I also suggest visiting my blog as I usually write about Hibernate and performance related problems.

When you are developing an enterprise application, do you consider designing for performance from the very beginning, or do you postpone it in the name of "premature optimization"?

I’ve seen many issues popping up during the last few years, and most of them occurred due to not thinking about the performance in advance. I think JDBC batching is the perfect example for this as there are lots of things you have to be careful about, like JDBC driver, underlying DB, not flushing in the middle of a transaction, reordering, etc.

In my opinion, it’s essential to consider performance from the beginning because there are so many things which might go wrong in the data-access layer.

We always value feedback from our users, so can you tell us what you’d like us to improve or are there features that we should add support for?

I’m really thankful for the Hibernate team because you guys are making a great tool for the community. I think Hibernate is currently in a state where most of the features are in place, and only minor adjustments are necessary so I wouldn’t add anything special here.

Thank you, Arnold, for taking your time. It is a great honor to have you here. To reach Arnold, you can follow him on Twitter.

Welcome to the Hibernate community newsletter in which we share blog posts, forum, and StackOverflow questions that are especially relevant to our users.


Don’t miss our Hibernate developer interviews with Anghel Leonard.

If you want to share your story about Hibernate, let us know, and we can share it with our huge community of passionate developers.


Brandur has written a very detailed explanation about the implementation of MVCC (Multi-Version Concurrency Control) in PostgreSQL. For a beginner’s overview of what MVCC is and how it works, check out this article as well.

Hibernate Envers is probably the easiest way to set up an audit log if you are already using JPA and Hibernate. Check out this article to see the best audit strategy to use when choosing Envers as your audit log implementation.

Running out of database sequence values is a very serious issue. This article explains how this had happened on a production system, and offers both a quick fix and a solution for this problem.

Not only that it provides a solid implementation of the JPA specification, but Hibernate can be used for all sorts of tasks like for getting access to the binding between JPA entities and the underlying DB objects (e.g. table, column). Check out this article for more details on this topic.

This article explains how to persist a List of String objects as an @ElementCollection. Although simple, @ElementCollection, like any unidirectional association, is not very efficient. A bidirectional @OneToMany association where the String element becomes part of the Child entity is a much more efficient alternative.

Time to upgrade

We just published three bugfix releases of Hibernate Search: 5.5.8.Final, 5.6.3.Final and 5.7.2.Final.

What’s new?

Here are the most notable changes:

  • HSEARCH-2851: Hibernate Search 5.5 now works correctly with Hibernate ORM 5.1.9 when using OSGi.

  • HSEARCH-2843: changing the limit/offset of a query now properly clears the query’s result cache with Elasticsearch.

  • HSEARCH-2858: @Spatial-annotated types with a @ContainedIn-annoted property no longer trigger an exception on startup.

For a full list of changes, please see the release notes:

How to get these releases

All versions are available on Hibernate Search’s web site.

Ideally use a tool to fetch it from Maven Central; these are the coordinates:


To use the experimental Elasticsearch integration you’ll also need:


Downloads from Sourceforge are available as well.

Feedback, issues, ideas?

To get in touch, use the following channels:

Hibernate Validator 6.0.2.Final released

Posted by    |       |    Tagged as Hibernate Validator Releases

Thanks to our users providing us feedback on our 6.0 release, we were able to fix a few annoying issues and we are happy to announce the release of Hibernate Validator 6.0.2.Final.

This is a recommended upgrade for everyone using Hibernate Validator 6.0.x and it is a drop-in replacement of 6.0.1.Final.

What’s new since 6.0.1.Final?

We fixed 2 annoying bugs:

  • HV-1471, reported by William Eddy - An important issue in the new value extraction infrastructure: it could lead to the engine trying to extract a value from an already unwrapped value;

  • HV-1470, reported by Jean-Sébastien Roy - The annotation processor might report an error in a perfectly valid use case: a constraint validator declared through the programmatic API or the XML configuration. This issue is only relevant to people using the annotation processor.

The Brazilian Portuguese translation was updated by Hilmer Chona and Thiago Mouta.

Marko also made a few improvements to the annotation processor regarding the value extraction support in HV-1395.

The complete list of fixed issues can be found on our JIRA.

Getting 6.0.2.Final

To get the release with Maven, Gradle etc. use the GAV coordinates org.hibernate.validator:{hibernate-validator|hibernate-validator-cdi|hibernate-validator-annotation-processor}:6.0.2.Final. Note that the group id has changed from org.hibernate (Hibernate Validator 5 and earlier) to org.hibernate.validator (from Hibernate Validator 6 onwards).

Alternatively, a distribution bundle containing all the bits is provided on SourceForge (TAR.GZ, ZIP).

If you want to benefit from the new features of this version on WildFly, we also provide WildFly patches for WildFly 10.1 and WildFly 11.0 Beta1 (wait for the synchronization to Maven Central). You can read about how to apply such patches here.

What’s next?

We will continue to release maintenance releases to fix quickly the issues reported by our users.

With your help, we hope to update the translations of the constraint messages in the future releases.

And finally, we also intend to explore potential features for a future spec revision. Always good to have feedback from the field before setting the API in stone.

Feedback, issues, ideas?

To get in touch, use the usual channels:

Meet Anghel Leonard

Posted by    |       |    Tagged as Discussions Hibernate ORM Interview

In this post, I’d like you to meet Anghel Leonard, a software developer, blogger, book author, and Java EE aficionado.

Anghel Leonard, align=

Hi, Leonard. Would you like to introduce yourself and tell us a little bit about your developer experience?

Hi Vlad, thanks for having me. My name is Anghel Leonard (@anghelleonard on Twitter), I’m living in a small village in Romania, and I’ve been a software developer for the last 17 years, mainly focusing on Java and Web development. I’m also a blogger and author of several books.

My career started as a Java developer in the oil field (Petrom S.A.). Mainly there I’ve been part of the team whose goal was to develop applications in the oil simulation field (Java desktop applications meant apply some specific mathematical models). After some time, we switched to web applications (based on HTML, Servlets /JSP and Struts) and we brought databases into the equation as well (especially MySQL and Visual FoxPro). About then I’ve started with Hibernate ORM, "native" API.

Shortly, I’ve started to learn Java EE (mainly, JSF, EJB, and JPA) and Spring. Further, I’ve worked for many years in GIS field developing RIA and SPA web applications. Since then I’m constantly using Hibernate implementation of the Java Persistence API (JPA) specification. By their nature, GIS RIA/SPA applications process a lot of data (spatial and non-spatial data) and must run fast, so I’ve always been interested to optimize the performance of the persistent layer. I can say that I’ve seen Hibernate "growing" and I’ve constantly tried to learn about every new feature and improvement it brought :)

Currently, I’m working as a Java CA. My main task here is to perform code reviews on a significant number of projects of different sizes, technologies, and areas of interest. Many of these projects use Hibernate "native" API and Hibernate JPA.

You are a very prolific writer, having published several books about JSF, Omnifaces, Hibernate, MongoDB and even JBoss Tools. Now that you are self-publishing your latest book, can you tell us the difference between working with a publisher and going on your own?

Well, I think that it is obvious that choosing between a publisher and self-publishing is a trade-off matter. From my experience, there are pros and cons on both sides and I can highlight the following aspects:

Publisher vs self-publishing pros:

  • publishers provide grammar and check spelling (this can be a major advantage for non-native English speakers, as me) and technical reviewers (usually, authors can recommend reviewers as well) while in self-publishing the author must take care of this aspects

  • publishers take care of book’s cover and index while in self-publishing the author must do it

  • publishers can consider the author very good and contact him for further contracts on the same topic while this is not true in self-publishing (at least, I did not hear of it)

  • publishers provide constant and consistent assistance during the writing process (e-mail or Skype) via editors, project coordinator, technical stuff, etc while in self-publishing this is not available

  • for authors is 100% costs free while in self-publishing the costs can seriously vary

  • publishers can be powerful brands on the market

Publisher vs self-publishing cons:

  • publishers can reject a book proposal for different reasons (e.g. they already have too many books on the suggested topic) while in self-publishing the chances to be accepted are significantly bigger

  • publishers work only with deadlines (each chapter has a fixed date and the book has a fixed calendar) while is self-publishing the author decides when to release an updated version and how significant the update will be

  • publishers provide "Errata" for book issues (typos, mistakes, technical leaks, content accuracy issues, etc) and those issues can be fixed only in subsequent versions of the book while in self-publishing the author can fix issues immediately and repeatable

  • publishers usually pay significantly smaller royalties in comparison with self-publishing

  • typically, publishers pay royalties at every 6 months, while in self-publishing is more often

  • publishers are not quite flexible about the book size, aspect, format, writing style, etc while in self-publishing these coordinates are very flexible

  • publishers require to be the only owner of the book content and it is forbidden to publish it in any other place or form while in self-publishing this restriction is not always applied

  • publishers set the price of the book without consulting the author while in self-publishing the author sets the price (moreover, the author can choose the price in a range of values)

  • publishers decide the discounts and donations policy while in self-publishing the author can provide coupons, discounts and make donations.

Your latest book is called "Java Persistence Performance Illustrated Guide". Could you tell us more about this new project of yours?

Sure thing.

Well, in the beginning, the content of this new book was not meant to be part of any book. The story is like this: Over time, I have collected the best online articles about Java persistence layer (JPA, Hibernate, SQL, etc) and, on my desk, I have some of the most amazing books about these topics.

I think there is no surprise for you if I say that your blog and book, High-Performance Java Persistence, are major parts of this collection.

In order to mitigate the performance issues related to persistence layer, I strongly and constantly recommend these resources to developers involved in persistence layer, but the remaining question is: in a regular day of work, how the members of a team can quickly understand/recognize a performance issue in order to fix it?

Well, there is no time to study in that moment, so I decided to have a new approach: have drawn of a specific performance issue and for 5-15 minutes talk on that draw (after all, "a picture is worth a thousand words"). This way, the audience can quickly understand/recognize the issue and have the hints to fix it.

Further, I’ve published these draws on Twitter, where I was surprised to see that even without the words (the talk), they were appreciated. Well, over time I’ve collected a significant number of draws and people started asking me if I will publish them somewhere (I remember that we had a little talk about this on Twitter as well). And, this is how the idea of the book was born. :)

The main reason of choosing the self-publishing approach was the fact that I’m not constrained by fix deadlines. The only extra-effort I’ve done was to find somebody to make the cover - it was designed and drawn by an excellent painter, Mr. Barsan Florian.

Now, the goal of this book is to act as a quick illustrated guide for developers that need to deal with persistence layer performance issues (SQL, JDBC, JPA, Hibernate (most covered) and Hazelcast).

Each drawing is accompanied by a short description of the issue and the solution. It’s like "first-aid", a quick and condensed recipe that can be followed by an extended and comprehensive article with examples and benchmarks, as you have on your blog.

Most of the applications that I reviewed are Java EE and Spring based applications. Since most of the performance penalties have their roots in the persistence layer, I tried to make a top 10 of the most frequent programming mistakes that cause them (this trend was computed from ~300 PRs in different projects and it is in progress):

  1. Having long or useless transactions (e.g. using @Transactional at class level on Spring controllers that delegate tasks to "heavy" services or never interact with the database)

  2. Avoiding PreparedStatement bind parameters and using "+" concatenations for setting parameters in SQL queries.

  3. Fetching too much data from the database instead of using a combinations of DTO, LIMIT/ROWNUM/TOP and JOINs (e.g. in the worst scenario: a read-only query (marked as read-only or not) fetches all entities, a stream is created over the returned collection, and afterwards, the findFirst stream terminal operation is executed in order to fetch and use further a single entity).

  4. Wrong configuration of batching (the team lives with the sensation that batching is working behind the scene, but they don’t check/inspect the actually SQLs and batch size)

  5. Bad usage or missing transaction boundaries (e.g. omitting @Transactional for read-only queries or executing separate transactions for a bunch of SQL statements that must run in a single transaction)

  6. Ignoring the fact that data is loaded eagerly.

  7. Don’t rely on a pool connection or avoid tuning the pool connection (Flexy Pool should be promoted intensively). Even worse, increase the connections number to 300, 400.

  8. Use unidirectional one-to-many associations with insert and delete entities operations

  9. Using CriteriaBuilder for all SQL statements and rely on whatever is generated behind the scene

  10. Lack of knowledge about Hibernate features (e.g. attributes lazy loading, bytecode enhancement, delay DB connection acquisition, suppress sending DISTINCT to the database, etc)

We always value feedback from our users, so can you tell us what you’d like us to improve or are there features that we should add support for?

First I want to congratulate the whole Hibernate team because is doing a great job! I really love the latest features and the comprehensive improvements in documentation. Taking into account the type of applications that I’m involved in, I will like to see the Hibernate - CDI integration ready.

Thank you, Leonard, for taking your time. It is a great honor to have you here. To reach Leonard, you can follow him on Twitter.

back to top