=46rom discussion on JPOX forum about the same issue :-

Now I can detach 2 or more copies of the very same persistent object.=20
Consequently if I start a PM and decide I'm attaching them both, you would=
=20
then expect the JDO implementation to play around with 2 persistent objects=
=20
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 go=
es=20
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 cac=
he=20
that one since the identity already exists in the L1 cache but referring to=
a=20
different object, breaking object uniqueness for an identity.



So if you had a flag "javax.jdo.option.AttachOnPersist" that effectively=20
changed the functionality of PM.makePersistent() to not return a COPY but t=
o=20
migrate the state of the passed object to persistent, then you hit this=20
problem above.

You could allow something of this form by imposing a restriction that if an=
=20
object needs attaching, and that "AttachOnPersist" flag is set, and the PM=
=20
already has a persistent object with that id then throw a JDOUserException.=
=20
Clearly the primary use-case is where the user detaches a single object, an=
d=20
then wants to attach the same thing, so they typically never hit the=20
duplicate detached object issue.


=2D-=20
Andy =A0(Java Persistent Objects - http://www.jpox.org)

[ Post a follow-up to this message ]