[bv-dev] TraversableResolver and JPA
Emmanuel Bernard
emmanuel at hibernate.org
Mon Oct 9 11:00:08 EDT 2017
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 at gmail.com> 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 at hibernate.org> 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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
More information about the beanvalidation-dev
mailing list