Uploaded image for project: 'Spring Data JPA'
  1. Spring Data JPA
  2. DATAJPA-1560

CPU consumption of IllegalArgumentException during id derivation for entities with composite keys



      I have been doing flame graph analysis to understand CPU usage for some of my applications. The application I was testing in this instance is a Spring Boot app using Spring data JPA + Hibernate with MySQL jdbc driver for persistence. The entity I was trying to persist has a composite key with 4 properties. The entity was saved successfully in the database and the functionality itself was not affected.

      From the flame graph (attachment: exception.png), I saw that a lot of CPU was used in filling stack traces for an IllegalArgumentException which is never used or causing any issues. I have attached the graph with this issue.

      On looking at the stack, it looks like for entities with composite primary keys, Spring JPA is checking if id has to be derived for every property of the composite primary key (IdClass). This is done by calling JPA's managedType method in MetaModelImpl. In the example I tested, my composite key had 4 properties and 4 exceptions were thrown for each of them and this happens every time I persist an entity. It easily multiplies in write-heavy workloads. And this is consuming a lot of CPU as more time is spent on creating these exceptions and stack traces.

      I think this situation can be avoided if javax/persistence/metamodel/Metamodel#getManagedTypes() is used, which provides a list of managed entities without throwing any exceptions. I submitted an issue in Hibernate issue tracker and the Hibernate implementation understandably throws the exception to conform to JPA.

      Can Metamodel#getManagedTypes be used instead of Metamodel#managedType?


        1. exception.png
          270 kB
        2. exception-2.png
          59 kB



            • Assignee:
              schauder Jens Schauder
              maheshsenni Mahesh Senniappan
              Last updater:
              Mark Paluch
            • Votes:
              0 Vote for this issue
              2 Start watching this issue


              • Created: