I've run into the exception below and I can't work out why I get it in one situation but not another:

net.sf.hibernate.NonUniqueObjectException: a different object with the same identifier value was already associated with the session: 66, of class: testing.om.Product

This is in the context of a Struts/Spring/Hibernate web application. I store a Product record in the HttpSession at the point when the user moves to a page to add or edit a StockItem (the Product contains a collection of StockItems). When they go to save the StockItem, I retrieve the Product from the HttpSession, delete the old associated StockItem from product.stockItems collection (if it's not new), add the new one and store the product. Editing an existing stock item this works just fine, no problem. When I add a new stock item, though, I get the exception about the product already existing. Why the difference? I use the same method for processing and storing the stock item record in each case. And why does Hibernate think I'm trying to create a new Product with the same identifier (in this case) rather than just updating an existing one? (I am using saveOrUpdate).

Hope someone can shed some light on this.

Hibernate does not think that you are creating a new Product with the same identifier. It is telling you have associated two instances of the same persistent object in the scope of the session.

Maybe you are rassociating objects using session.lock() as you go through you page flow and calling the backend. If this is the case, make sure that you are not always reusing the same session.

Good luck,
Vincent.

Thanks. What puzzles me is that the way the object is stored is identical for edits (which work) and adds (which don't). Could it be something to do with Spring's OpenSessionInViewFilter?

To answer your question, I am not familiar with Spring yet.

Maybe you could post the code where you retrieve the Product and reassociate it to the session prior to saving it

Are you in a multi-layer environment? Do you reassociate objects to the session when you cross your layers, or do you have the session available on your front end?

Sorry, I was away for a while, just got back.

I discovered the source of the problem. It was that the StockItem's association to Product had "cascade=save-update" instead of 'cascade=none' (i.e., the many-to-one definition in the StockItem mapping). As soon as this was changed to 'none', the problem went away. Still not sure exactly why this should be so, though.

You guys are living dangerous. The exception has a very clear and important meaning: You are doing something wrong in your transaction processing and/or in the way you handle object identity and object instances. You have to understand what merge() (or in Hibernate2 saveOrUpdateCopy) is good for. Then read everything you can find again about the Session's scope and identity guarantees. Then understand Detached Objects. Then fix your problem right. No, Spring won't help, just complicate the situation.