Transaction commit fails with TransientObjectException: persistent instance references an unsaved transient instance

[tcordel]

Hi,

Overview

We met an unexpected error upgrading to spring-boot 3.4.0

I'm not sure this bug deals with spring-data, but i have not been able to reproduce the default using hibernate directly ; maybe you may provide new directions of investigations...

Here is a sample project representing the default with the minimal configuration needed to reproduce it : https://github.com/tcordel/jpa-named-query/tree/main

org.springframework.dao.InvalidDataAccessApiUsageException: org.hibernate.TransientObjectException: persistent instance references an unsaved transient instance of 'com.example.demo.entities.UserNotifEntity' (save the transient instance before flushing)
   	at org.springframework.orm.jpa.EntityManagerFactoryUtils.convertJpaAccessExceptionIfPossible(EntityManagerFactoryUtils.java:368)
   	at org.springframework.orm.jpa.vendor.HibernateJpaDialect.translateExceptionIfPossible(HibernateJpaDialect.java:246)
   	at org.springframework.orm.jpa.JpaTransactionManager.doCommit(JpaTransactionManager.java:566)

Details

This issue appears only if the optional fetch is done here : NotificationService

Entities

classDiagram
    class ApplicationEntity {
          
    }
    class UserEntity {

    }
    class TypeNotificationEntity{

    }
    class UserNotifEntity {
        +UserEntity User
        +TypeNotificationEntity typeNotif
    }
    class UserNotifAppliEntity {
        +UserNotifEntity UserNotif
        +ApplicationEntity application
    }

Loading

Tests

List of the tests present in DemoApplicationTests :

• buggyWithTransactionalUsingNamedQueryForDeletion : This test presents the bug
• workingWithoutTransactional : condition of bug but removing @transactional annotation on service makes it pass
• workingRequiringNewTransactionForDeletion : condition of bug but requiring new transaction before calling named query makes it pass
• workingInSameConditionWithJpqlForDeletion : condition of bug but using jpql for deletion makes it pass
• workingInSameConditionWithCriteriaForDeletion: consition of bug but using criteria for deletion make it pass

Thanks for your time :)

[quaff]

I'm pretty sure it caused by bug fix hibernate/hibernate-orm@055570c, I'm not sure you are using in correct way, I didn't dig too much because the code is a bit hard to read.

[mp911de]

I can reproduce the issue with using the EntityManager:

CriteriaBuilder cb = entityManager.getCriteriaBuilder();
CriteriaQuery<UserNotifEntity> criteriaDelete = cb.createQuery(UserNotifEntity.class);
Root<UserNotifEntity> from = criteriaDelete.from(UserNotifEntity.class);
criteriaDelete.where(cb.equal(from.get("user"), user), cb.equal(from.get("typeNotif"), typeNotif));
Query query = entityManager.createQuery(criteriaDelete);
List resultList = query.getResultList();
for (Object o : resultList) {
	entityManager.remove(o);
}

On the flip side, using a CriteriaDelete or a JPQL delete query doesn't show this behavior. That being said, I consider the issue a Hibernate problem and there is nothing we can do about.

[tcordel]

Nice thank you!

[palhoye]

This issue was introduced with Hibernate 6.6.
Hibernate 6.5.3 does not have this issue.
Short term work-around is to specify Hibernate dependency as 6.5.3.Final.

[tcordel]

For anyone interested the Issue has been reported to hibernate team : https://hibernate.atlassian.net/browse/HHH-18936 Downgrading is not possible for us due to another hibernate issue ( https://hibernate.atlassian.net/browse/HHH-18400). But thanks for the tips. Le ven. 27 déc. 2024, 20:31, Pål Høye ***@***.***> a écrit :

…

This issue was introduced with Hibernate 6.6. Hibernate 6.5.3 does not have this issue. Short term work-around is to specify Hibernate dependency as 6.5.3.Final. — Reply to this email directly, view it on GitHub <#3712 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AOEC35L6Z3F2Q5RESIJ53DT2HWTHZAVCNFSM6AAAAABTPQ3LMSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKNRTHE3TINBQGA> . You are receiving this because you authored the thread.Message ID: ***@***.***>