db-jdo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Matthew T. Adams" <matthew.ad...@xcalia.com>
Subject RE: RETRY: Transient instance referencing a detached instance?
Date Thu, 06 Oct 2005 23:10:13 GMT
I was thinking along the following lines.

When the user calls pm.makePersistent(t), where t is a transient instance
that may contain a reference to a detached instance, the JDO implementation
runs the reachability algorithm.  Any detached objects found in the graph
are replaced by their corresponding attached copies (perhaps via an implicit
pm.attachCopy call).  Once the attachment process is complete, the graph
consists of transient objects referencing newly attached, and thereby
persistent, references.  At that point, the use case that already exists
today takes over, where the there are transient instances referencing
persistent-dirty or persistent-clean instances.

There exists the possibility that more than one distinct detached instance
is found that has the same object id as another (two detached copies of the
same persistent instance), and I'd say that we do not specify which detached
instance gets attached, but the user is guaranteed that one and only one
instance is attached, and any references to the different detached copies
are replaced by a reference to the one and only attached, persistent copy.  

Conceptually, this requires two passes through the graph, but it might be
possible to do this with only one pass; that's up to the individual
implementations.

I don't really see any new states here; the transient instances are still
transient or persistent-new, and the detached objects' replacements (the
attached copies) are either in the persistent-dirty or persistent-clean
states.

It's entirely possible that I'm oversimplifying the solution here, but it
seems doable.  Thoughts?

--matthew

-----Original Message-----
From: Craig Russell [mailto:Craig.Russell@Sun.COM] 
Sent: Thursday, October 06, 2005 3:04 PM
To: jdo-dev@db.apache.org; JDO Expert Group
Subject: Re: RETRY: Transient instance referencing a detached instance?


Hi,


If you would, please go through the state transitions of detached objects
becoming persistent via makePersistent or via reachability. Include what
happens to detached objects at commit and rollback.


I was unable to do this without creating numerous additional states
(detached-persistent, detached-persistent-dirty,
detached-persistent-deleted) and it was hideous. 


Let me know what you find by doing the analysis and we can talk about it.
The clean way of doing it is still to allow mixing transient instances with
either detached or persistent object graphs but keeping detached and
persistent graphs distinct.


Thanks,


Craig


On Oct 5, 2005, at 5:31 PM, Matthew T. Adams wrote:


Excellent.  Unless there's some technical reason that a user advocate like
me can't see, let's make this change.  Craig, others, can you please
comment?


--matthew




-----Original Message-----
From: Andy Jefferson [mailto:andy@jpox.org] 
Sent: Wednesday, October 05, 2005 12:09 PM
To: 'JDO Expert Group'; jdo-dev@db.apache.org
Subject: Re: RETRY: Transient instance referencing a detached instance?






Would it be cleaner to not allow transient instances to be 


included in


attachCopy() graphs at all?  Sounds that way to me.




No, I'd like to continue to allow transient instances to be 


included in


attachCopy graphs.  I'd like to **add** the ability for 


detached objects to


be included in makePersistent graphs.




I'll second this requirement.
I asked for it on 16 Sep - see the posting in the EG archives titled 
"makePersistent with a detached object reachable".
We need a consistent interface for persistence, and having one method 
(makePersistent) doing things one way and another(attachCopy) doing it 
another doesn't help IMHO.


A user wants to persist a new object. They want to relate it 
to another object 
(in this case detached, but it could be any old object), and 
then do the 
persist. Having to work out which method to call in what 
circumstances, 
dependent on what objects you just happen to have in the graph is not 
user-friendly.




-- 
Andy












Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!



Mime
View raw message