A bit of context first: we are developing a Spring-based web service (SOAP) application, backed by a database. We perform bean validation just before calling the @Service layer, to verify that input data conforms to the service contract. We are not validating JPA entities, because we already have check constraints in the database.
During a profiling session with Dynatrace/Java Mission Control, we have found that an approximate 10% of the CPU time is spent in _Throwable.getStackTrace()_, which is heavily invoked by Hibernate Validator. Find attached some pictures.
After some analysis, we have found that this problem is mostly caused by Eclipselink, in a method called isJpa1CompatibleCaller(). Incidentally, we are not validating JPA entities, so... why spend time on checking whether the attribute can be reached or if it is jpa1-compatible?
As it appears, just because JPA 2 is in the classpath, nothing more. The validation of JPA entities can be disabled setting the "javax.persistence.validation.mode" property to NONE, but that won't disable traversing DTOs as if they were JPA entities...
I suggest that JpaTraversableResolver is used only for JPA entities, or at least can be disabled when the persistence validation is set to NONE. This suggestion is in line with another JIRA issue: https://hibernate.atlassian.net/browse/HV-1487
|
|
