On 6 Oct 2017, at 16:13, Guillaume Smet <guillaume.smet(a)gmail.com&gt; wrote: Hi, A user of Hibernate Validator reported an interesting case here: https://hibernate.atlassian.net/browse/HV-1489 . The fact is that a method implemented in WebLogic is suboptimal but I think there is an interesting point here anyway. In the spec, we say that when we find a JPA implementation in the classpath, we enable the JPATraversableResolver. This adds an overhead even for unmanaged entities as there is no way to tell if an object is a managed entity or a plain bean. In EclipseLink, they override the traversable resolver in the context when validating the object on persist and I think it might be good idea: their JPA resolver is only used when persisting entities and when other objects are validated, the default traversable resolver is used - in the case of our user, it uses our JPATraversableResolver which leads to the issue he reported. There is another advantage to this approach: the TraversableResolver is in the JPA implementation so it can use optimized calls to internal classes, instead of relying on the JPA API. The problem with such an approach is that the user can't override the traversable resolver set by the JPA provider. There is another trade-off: if the user tries to validate an entity outside of the JPA persist listener, it won't use the specific JPA resolver. I wasn't there when this section was added so I'm not sure what was exactly the rationale for it. I think we might have underestimated the overhead of our approach. We have a cache but the cache is per validation call so if you end up validating each object only once per call (and it's probably the most common case), the cache doesn't bring anything to you (except an additional overhead). -- Guillaume _______________________________________________ beanvalidation-dev mailing list beanvalidation-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/beanvalidation-dev

On 9 Oct 2017, at 16:24, Guillaume Smet <guillaume.smet(a)gmail.com&gt; wrote: OK so we can't really do anything about it. I tuned HV to be a bit more efficient and avoid an additional cache lookup on cascade with the JPA TraversableResolver (the isCascadable() method always returns true so we don't need to cache it). It might be a good idea to discuss with the ORM people to see if we can be a bit more efficient in the Hibernate case. There is a TODO in our code about introducing some specific optimizations. -- Guillaume On Mon, Oct 9, 2017 at 11:56 AM, Emmanuel Bernard <emmanuel(a)hibernate.org&gt; wrote: > The reason was to be able to validate entities outside of explicit JPA calls and not cross the lazy loading boundaries. > It would become a very big overhead to load data from the database for validation. _______________________________________________ beanvalidation-dev mailing list beanvalidation-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/beanvalidation-dev

Yes, the PersistenceUtil API is pretty basic and you can't do much about that. And you're right about Hibernate not being the only JPA provider in the classpath. I didn't think of this case. What would be possible is to do what WebLogic did ie have a specific TraversableResolver when the validation is triggered by ORM directly. It wouldn't help the case of the other validation calls though. On Mon, Oct 9, 2017 at 5:00 PM, Emmanuel Bernard <emmanuel(a)hibernate.org&gt; wrote: > If you can detect that this is not an entity class, then you could cache this information in a bounded cache (weak key). It should help a lot. But I don't think PersistenceUtil has such API and if you use Hibernate specific APIs, you are never guaranteed than you are the only JPA provider in the classpath unless you look for them or the app server tells you. Tricky optimisation. > >> On 9 Oct 2017, at 16:24, Guillaume Smet <guillaume.smet(a)gmail.com&gt; wrote: >> >> OK so we can't really do anything about it. >> >> I tuned HV to be a bit more efficient and avoid an additional cache >> lookup on cascade with the JPA TraversableResolver (the isCascadable() >> method always returns true so we don't need to cache it). >> >> It might be a good idea to discuss with the ORM people to see if we >> can be a bit more efficient in the Hibernate case. There is a TODO in >> our code about introducing some specific optimizations. >> >> -- >> Guillaume >> >> On Mon, Oct 9, 2017 at 11:56 AM, Emmanuel Bernard >> <emmanuel(a)hibernate.org&gt; wrote: >>> The reason was to be able to validate entities outside of explicit JPA calls and not cross the lazy loading boundaries. >>> It would become a very big overhead to load data from the database for validation. >> _______________________________________________ >> beanvalidation-dev mailing list >> beanvalidation-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev > > > _______________________________________________ > beanvalidation-dev mailing list > beanvalidation-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/beanvalidation-dev _______________________________________________ beanvalidation-dev mailing list beanvalidation-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/beanvalidation-dev