db-jdo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andy Jefferson <a...@jpox.org>
Subject Re: 2.1 Spec: detached-dirty parameters to makePersistent() when DetachAllOnCommit=true
Date Tue, 07 Aug 2007 18:35:31 GMT
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)

Mime
View raw message