Please correct my understanding: I can not cause a NonUniqueObjectException when I just loaded the object. I am *not* changing the id, just some properties.

Some other relevant info is that I am updating a class "Project" and receiving the exception about "Issue". This is Hibernate 2.1.1. Just reproduced it under 2.1.2 as well.

I am receiving the following:

net.sf.hibernate.NonUniqueObjectException: a different object with the same identifier value was already associated with the session: c5bb43a8fa0d03a200fa127ba9940002, of class: com.terravox.issuetracker.model.Issue
at net.sf.hibernate.impl.SessionImpl.checkUniqueness(SessionImpl.java:1605)
at net.sf.hibernate.impl.SessionImpl.doUpdateMutable(SessionImpl.java:1377)
at net.sf.hibernate.impl.SessionImpl.doUpdate(SessionImpl.java:1403)
at net.sf.hibernate.impl.SessionImpl.saveOrUpdate(SessionImpl.java:1327)
at net.sf.hibernate.engine.Cascades$4.cascade(Cascades.java:114)
at net.sf.hibernate.engine.Cascades.cascade(Cascades.java:436)
at net.sf.hibernate.engine.Cascades.cascadeCollection(Cascades.java:526)
at net.sf.hibernate.engine.Cascades.cascade(Cascades.java:452)
at net.sf.hibernate.engine.Cascades.cascade(Cascades.java:503)
at net.sf.hibernate.engine.Cascades.cascade(Cascades.java:482)
at net.sf.hibernate.impl.SessionImpl.preFlushEntities(SessionImpl.java:2557)
at net.sf.hibernate.impl.SessionImpl.flushEverything(SessionImpl.java:2197)
at net.sf.hibernate.impl.SessionImpl.flush(SessionImpl.java:2186)
at net.sf.hibernate.transaction.JDBCTransaction.commit(JDBCTransaction.java:61)
at org.springframework.orm.hibernate.HibernateTransactionManager.doCommit(HibernateTransactionManager.java:339)
at org.springframework.transaction.support.AbstractPlatformTransactionManager.commit(AbstractPlatformTransactionManager.java:297)
at org.springframework.transaction.support.TransactionTemplate.execute(TransactionTemplate.java:110)
at com.terravox.issuetracker.view.EditEntityForm.onSubmit(EditEntityForm.java:69)

Here is the relevant code:

public ModelAndView onSubmit(Object command) throws ServletException {
final String[] ignoreProperties = {"id"};
final BeanWrapper wrapper = new BeanWrapperImpl(command);
final Object finalCommand = command;
// Do the update in a tx
transactionTemplate.execute( <<<<==== ***Line 69***
new TransactionCallback() {
public Object doInTransaction(TransactionStatus status) {
if (log.isDebugEnabled()) {
log.debug("Transaction Status: " + status.isNewTransaction());
}
Object existing = dataManager.retrieve(
(String) wrapper.getPropertyValue("id"));
BeanUtils.copyProperties(finalCommand, existing, ignoreProperties);
dataManager.update(existing);
// No return needed
return null;
}
});
return new ModelAndView(getSuccessView());
}

"dataManager.retrieve()" is a straight wrap around Session.load().

Any thoughts?

Thanks,

A.

--
Adam Sherman
Tritus CG Inc.
+1 (613) 797-6819
http://www.tritus.ca/

Note: It is BeanUtils.copyProperties(target, source)

Look at saveOrUpdateCopy, I think it does exactly what you are trying to do.

Okay, thought this was jakarta BeanUtils. The exception means you have allready previously loaded or otherwise associated with the session another object with the same id. Check for that.

I've been looking for exactly that for days.

Note that the exception is talking about a child object, not the object I'm trying to update. But yes, since the child object is reachable from multiple points in my object graph, it will already have been loaded. This is a common use case.

Thanks for your time,

A.

Probably your unsaved-value mapping on the child object is incorrect?

It is set to null. Also, why would changing a simple property on the parent cause this error regarding the child?

Thanks,

A.

same problem and I agree, retrieving an entity several times within a session is a common usecase even for med-complex data graphs. to workaround this problem I wrapped the hibernate-session and introduced a layer acting as a instance-repository.
nevertheless I keep getting this exception for some of my objects.

assume a A referencing multible Bs. The B itself references back its containing A and holds another LeftA and RightA. even if my debugger swears, that i.e. the Container-A and Right-A have the same JVM-identity, this exception is thrown, making me wonder if the exception isn't misleading.

I couldn't isolated the problem and havn't debugged through the hibernate-code properly yet, because my src and jar are not matching too well (yes, I know, maybe tomorrow) but at the moment I am on the the trace of equals/hashcode, because I have problems with remove()/contains() etc. due to changing uids, too (a TEMPxxx uid for transient objects in the repository-layer mentioned above is replaced by a uid generated by hibernate). Messing around with getEntity() in SessionImpl does not help either.

I assume it is a nice melange of well hidden bugs. Anyway I think it would be nice having a hibernate that deals with the problem of multible instances of a single entity within a session.

Hibernate deals incredibly elegantly with this problem - by disallowing the possibility. This is a basic feature of object persistence: object identity <=> persistent identity in the scope of a persistence context (Session).

mhh, sure it is important not having multible instances of a persistent entity flying around everywhere and i strongly believe hibernate works very elegantly (oh my, if I think back to ejb, tssch), yes. but i havn't understood how to build a good architecture around hibernate, yet. because my programming often ends up in a dead-end-implementation and I have to iterateOverCollections/ useRreflection/ workaroundHereAndThere instead of simply using a query. and a growing app sometimes makes it hard to isolate problems. that makes me believe having a build-in 'instance repository layer' would be nice. something that executes queries but delivers only the session-singelton instance of an entity.

i started to dig a little in your wiki, maybe this will do the trick and help me learn how to hide my bugs less good. because bulging with strange errors for days without bringing the application any farer is depressing. guess reading and learning is a good way to start. and best is: I can do so outside and watch the summer coming up :)