-
Notifications
You must be signed in to change notification settings - Fork 41.2k
NullPointerException during JPA deleteAll with lazy collections #35617
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Thanks for the sample. While I haven't managed to reproduce the problem without any usage of Spring, I have reproduced it without Spring Boot and Spring Data JPA. I've pushed a commit to my fork of your sample that just uses Spring Framework and Hibernate. It should fail with the same NPE.
Given that we can't (yet?) reproduce the problem without Spring Framework, I think we should get the Framework team to take a look. To that end, please open a Spring Framework issue referencing this issue and my updated version of your sample. |
I think it's bug of hibernate 6.2, It works fine when downgrade to 6.1.7, you should report to hibernate team not spring team. |
@pwandl already said that in the opening comment:
However, thus far we've been unable to reproduce the problem without Spring. If you have managed to do so, @quaff, please do share the code. |
I would take a look if @pwandl share the code that works fine using hibernate directly without any spring components. |
As far as I was able to reproduce this, neither Spring transaction management nor The one thing that makes it pass is removing the Jakarta EL provider So it looks like something is reacting to the presence of a Jakarta EL provider here, registering some special handling that ultimately breaks persister availability for lazy collection introspection. I have a suspicion that this is related to Hibernate Validator but it might be in Hibernate ORM 6.2 itself since a plain downgrade to ORM 6.1.7 makes the problem go away. In any case, this is definitely a Hibernate interaction problem. If someone has the cycles for it, please try to reproduce it with plain Hibernate (bringing a Jakarta EL provider onto the classpath) and report it to the Hibernate project. |
That matches what I saw too. It's size-related validation that calls a method on |
I originally could not reproduce this in the form of a test in You got a point there that without an EL provider, Hibernate ORM seems to back off from applying Hibernate Validator completely. A standalone Hibernate Validator setup fails with a proper exception if there is no EL provider on the classpath; I suppose Hibernate ORM silently swallows that and simply does not validate then. In any case, I expect the |
P.S.: The early failure for an incomplete Hibernate Validator setup can be enforced via |
My attempt to reproduce the problem without Framework is here. The debugger shows |
That almost hits the spot, it just shouldn't reuse the EntityManager instance between the transactions but rather create a fresh EntityManager per transaction. The following change to the pure JPA version makes the same exception appear for me:
|
Thanks, @jhoeller. @pwandl I've updated my fork of your example and it now reproduces the problem with pure JPA/Hibernate in the
|
Thanks for the detailled analysis! |
Since upgrading to Spring Boot 3.1.0 from 3.0.6 we are experiencing NPEs when calling .deleteAll() on Spring Data JPA repositories, but not for each entity. I suspect it is related to entities which contain lazy collections, but could not narrow it down further yet.
I have extracted a minimal sample application which shows the issue: https://github.com/pwandl/spring-hibernate-bug-demo
It seems to only occur if the transaction calling .deleteAll has not previously modified the to-be-deleted entities. I was not yet able to reproduce the issue using hibernate directly without any spring components, so I suspect that it might be related to some spring component, even though the issue does not occur when downgrading hibernate to 6.1.7
The text was updated successfully, but these errors were encountered: