# TransientObjectException after upgraded to Hibernate core 6.6.15.Final
**URL:** https://discourse.hibernate.org/t/transientobjectexception-after-upgraded-to-hibernate-core-6-6-15-final/11584
**Category:** Hibernate ORM
**Created:** [June 20, 2025, 7:28am UTC](https://discourse.hibernate.org/t/transientobjectexception-after-upgraded-to-hibernate-core-6-6-15-final/11584 "2025-06-20T07:28:59Z")
**Posts on this page:** 4
**Page:** 1
### Author:  [@Bhargav\_Ruparel](https://discourse.hibernate.org/u/Bhargav_Ruparel)
#### Post date: [June 20, 2025, 7:28am UTC](https://discourse.hibernate.org/t/transientobjectexception-after-upgraded-to-hibernate-core-6-6-15-final/11584/1 "2025-06-20T07:28:59Z")
We were trying to upgrade to **Hibernate Core 6.6.15.Final** and encountered the following exception while attempting to save a record:
```auto
org.hibernate.TransientObjectException: persistent instance references an unsaved transient instance of 'com.entityName' (save the transient instance before flushing)
```
After investigating, I found that this issue is likely related to the following change:
👉 [clean up logic in CHECK\_ON\_FLUSH · hibernate/hibernate-orm@8686392 · GitHub](https://github.com/hibernate/hibernate-orm/commit/8686392afe6d4eb0eef704a62ed2d87ba79fca46)
And I noticed a similar issue discussed here:
👉 [Instance save transient before](https://discourse.hibernate.org/t/instance-save-transient-before/10293)
However, the workaround suggested in that discussion would be difficult to apply across our codebase and could cause significant disruption as We have 500 plus `hbm.xml` files
**Is there any other recommended configuration or workaround to handle this issue more gracefully?**
Also, do you know if Hibernate plans to address or improve this behavior in any upcoming releases?
---
### Author:  [@beikov](https://discourse.hibernate.org/u/beikov)
#### Post date: [June 20, 2025, 7:38am UTC](https://discourse.hibernate.org/t/transientobjectexception-after-upgraded-to-hibernate-core-6-6-15-final/11584/2 "2025-06-20T07:38:49Z")
There is nothing to improve. You have to manage both sides of your associations, then you won’t have any exceptions.
---
### Author:  [@Igor\_Erdoiza](https://discourse.hibernate.org/u/Igor_Erdoiza)
#### Post date: [September 24, 2025, 9:15am UTC](https://discourse.hibernate.org/t/transientobjectexception-after-upgraded-to-hibernate-core-6-6-15-final/11584/3 "2025-09-24T09:15:26Z")
Hi everyone.
This is the first time I post and I know I will not be welcome but I do wanted to say something: I think it’s reckless to force to manage both sides of an association. If you remove an element of the N side of the relation it should never involve the management from the 1 side. It feels like an atrocious decision.
Best regards
---
### Author:  [@beikov](https://discourse.hibernate.org/u/beikov)
#### Post date: [September 24, 2025, 2:45pm UTC](https://discourse.hibernate.org/t/transientobjectexception-after-upgraded-to-hibernate-core-6-6-15-final/11584/4 "2025-09-24T14:45:03Z")
In the past, I was trying to defend the stance that changing just the owning side of an association should be enough, and that the inverse side should be ignored, but since downstream projects like Hibernate Search and Envers depend on data being in sync, it’s best that everyone who uses Hibernate just keeps the models in sync.
The easiest solution to do that is, not allow e.g. collection mutations directly, but always go through dedicated methods e.g. `addChild()`/`removeChild()` that will manage the inverse side as well.