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: VOTE [URGENT] Issue 136: Change signature of makePersistent
Date Tue, 06 Dec 2005 17:55:34 GMT
+1, but you probably already knew that.  :)

-----Original Message-----
From: Craig.Russell@Sun.COM [mailto:Craig.Russell@Sun.COM] 
Sent: Tuesday, December 06, 2005 9:52 AM
To: JDO Expert Group; Apache JDO project
Subject: VOTE [URGENT] Issue 136: Change signature of makePersistent


Javadogs,


I'd like to tally the vote on this issue by close of business Thursday
8-Dec-2005.


This issue was renamed to highlight the interface change. 


Please vote to adopt this proposal or offer a reason to reject it. It's the
most significant change for a few months, as it modifies the core method of
persistence.


Rationale: There are so few differences between makePersistent and
attachCopy, it's confusing. The only significant differences between the
APIs is in the treatment of transient instances. MakePersistent makes
transient instances transition to persistent-new; attachCopy copies
transient instances.


The proposal is to remove attachCopy, change the signature of makePersistent
and makePersistentAll to return the instance(s). 


The semantics of makePersistent change slightly from the specification.
Currently, detached instances in the object graph cause an exception to be
thrown. With this change, detached instances are located in the persistent
cache and any dirty fields are applied to the persistent instance.


With this change, there is no standard way to attach the same object graph
to multiple persistence managers. If this becomes an issue, we can consider
adding a method to JDOHelper that copies a complete object graph so the
copies can be attached to multiple persistence managers. But practical
experience has not shown this to be an issue.


<proposed 12.6.7>
Object makePersistent (Object pc);
Object [] makePersistentAll (Object[] pcs);
Collection makePersistentAll (Collection pcs);
A12.5.7-6A [These methods make transient instances persistent and apply
detached instance changes to the cache. They must be called in the context
of an active transaction, or a JDOUserException is thrown.] A12.5.7-6B [For
a transient instance, they will assign an object identity to the instance
and transition it to persistent-new.] Any transient instances reachable from
this instance via persistent fields of this instance will become
provisionally persistent, transitively. That is, they behave as
persistent-new instances (return true to isPersistent, isNew, and isDirty).
But A12.5.7-6C [at commit time, the reachability algorithm is run again, and
instances made provisionally persistent that are not currently reachable
from persistent instances will revert to transient.]
For a detached instance, they locate or create a persistent instance with
the same JDO identity as the detached instance, and merge the persistent
state of the detached instance to the persistent instance. Only the state of
persistent fields is merged. If non-persistent state needs to be copied, the
application should use the jdoPostAttach callback or the postAttach
lifecycle event listener. Any references to the detached instances from
instances in the closure of the parameter instances are modified to refer to
the corresponding persistent instance instead of to the detached instance.
During application of changes of the detached state, if the JDO
implementation can determine that there were no changes made during
detachment, then the implementation is not required to mark the
corresponding instance dirty. A12.6.8-28 [If it cannot determine if changes
were made, then it must mark the instance dirty.]
No consistency checking is done during makePersistent. If consistency
checking is required by the application, then flush or checkConsistency
should be called after attaching the instances.
A12.5.7-7 [These methods have no effect on parameter persistent instances
already managed by this PersistenceManager.] A12.5.7-8 [They will throw a
JDOUserException if the parameter instance is managed by a different
PersistenceManager.]
A12.6.7-1 [If an instance is of a class whose identity type (application,
datastore, or none) is not supported by the JDO implementation, then a
JDOUserException will be thrown for that instance.]
The return value for instances in the transient or persistent states is the
same as the parameter value. The return value for detached instances is the
persistent instance corresponding to the detached instance.
The return values for makePersistentAll methods correspond by position to
the parameter instances.
</spec 12.6.7>




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