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 with when the above entity persistence validation is set to NONE .
|
|
