db-jdo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Craig L Russell <Craig.Russ...@Sun.COM>
Subject VOTE [URGENT] Issue 136: Change signature of makePersistent
Date Tue, 06 Dec 2005 17:52:10 GMT

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  
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  
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!

View raw message