Hibernate Error: a different object with the same identifier value was already associated with the session

I essentially have some objects in this configuration (the real data model is a bit more complex):

• A has a many-to-many relationship with B. (B has inverse="true")
• B has a many-to-one relationship with C. (I have cascade set to "save-update")
• C is a kind of type/category table.

Also, I should probably mention that the primary keys are generated by the database on save.

With my data, I sometimes run into problems where A has a set of different B objects, and these B objects refer to the same C object.

When I call session.saveOrUpdate(myAObject), I get a hibernate error saying: "a different object with the same identifier value was already associated with the session: C". I know that hibernate can’t insert/update/delete the same object twice in the same session, but is there some way around this? This doesn’t seem like it would be that uncommon of a situation.

During my research of this problem, I have seen folks suggest the use of session.merge(), but when I do that, any “conflicting” objects get inserted into the database as blank objects with all values set to null. Clearly that isn’t what we want.

[Edit] Another thing I forgot to mention is that (for architectural reasons beyond my control), each read or write needs to be done in a separate session.

Answer

Most probably its because the B objects are not referring to the same Java C object instance. They are referring to the same row in the database (i.e. the same primary key) but they’re different copies of it.

So what is happening is that the Hibernate session, which is managing the entities would be keeping track of which Java object corresponds to the row with the same primary key.

One option would be to make sure that the Entities of objects B that refer to the same row are actually referring to the same object instance of C. Alternatively turn off cascading for that member variable. This way when B is persisted C is not. You will have to save C manually separately though. If C is a type/category table, then it probably makes sense to be that way.