From discussion on JPOX forum about the same issue :- Now I can detach 2 or more copies of the very same persistent object. Consequently if I start a PM and decide I'm attaching them both, you would then expect the JDO implementation to play around with 2 persistent objects with the same underlying identity?
Or to give an example :- * Object "x" is persistent with id "xId". * I detach "xd1" and "xd2", both with the same identity "xId". * I then start a PM and attach "xd1" and this migrates into P_CLEAN, and goes into the L1 cache as such referenced by the id "xId". * I then attach "xd2" and this migrates to P_CLEAN, and ... oh we can't cache that one since the identity already exists in the L1 cache but referring to a different object, breaking object uniqueness for an identity. So if you had a flag "javax.jdo.option.AttachOnPersist" that effectively changed the functionality of PM.makePersistent() to not return a COPY but to migrate the state of the passed object to persistent, then you hit this problem above. You could allow something of this form by imposing a restriction that if an object needs attaching, and that "AttachOnPersist" flag is set, and the PM already has a persistent object with that id then throw a JDOUserException. Clearly the primary use-case is where the user detaches a single object, and then wants to attach the same thing, so they typically never hit the duplicate detached object issue. -- Andy (Java Persistent Objects - http://www.jpox.org)
