org.hibernate.validator.internal.engine.resolver.JPATraversableResolver and thus also org.hibernate.validator.internal.engine.ValidatorImpl are not Thread-Safe which according to the contract of javax.validation.TraversableResolver and javax.validation.Validator they must be.

In particular, JPATraversableResolver ultimately calls org.hibernate.jpa.internal.util.PersistenceUtilHelper#isLoadedWithReference which uses PersistenceUtilHelper$MetadataCache. This class has a //TODO not really thread-safe and from the code it’s obvious that it isn’t thread-safe as it uses a simple WeakHashMap with no synchronization and there is nothing in the call chain doing any synchronization.

Here is a stacktrace that shows the call chain.

org.hibernate.jpa.internal.util.PersistenceUtilHelper$MetadataCache.getClassMetadata(PersistenceUtilHelper.java:424)
        at org.hibernate.jpa.internal.util.PersistenceUtilHelper.isLoadedWithReference(PersistenceUtilHelper.java:216)
        at org.hibernate.jpa.HibernatePersistenceProvider$1.isLoadedWithReference(HibernatePersistenceProvider.java:186)
        at javax.persistence.Persistence$PersistenceUtilImpl.isLoaded(Persistence.java:155)
        at org.hibernate.validator.internal.engine.resolver.JPATraversableResolver.isReachable(JPATraversableResolver.java:52)

This is causing us some issues as we’re using org.hibernate.validator.internal.engine.ValidatorImpl in a massive parallel context and from time to time we’re seeing deadlocks in the system with the above stacktrace when starting the system.