Re: Proposal for JDO-258 and JDO-273

[Craig L Russell]

Hi Michael, Good work on this. On Jan 17, 2006, at 9:01 AM, Michael Watzek wrote: Hi, JDO-258 and JDO-273 introduce new lifecycle states related to detachment and persistent-nontransactional-dirty. Below you find a summary of new states, operations, and state transitions to be implemented by the TCK in order to resolve these issues. Afterwards, you find some implementation hints and questions. New states: ---------- - detached-clean - detached-dirty - persistent-nontransactional-dirty New operations: -------------- - serialization - detach New JDO properties: ------------------ - DetachAllOnCommit State transitions: ----------------- - persistent-clean                  -> detached-clean   (detachCopy, detachCopyAll, serialization, commit and DetachAllOnCommit is true) - persistent-dirty                  -> detached-dirty You can get rid of this transition, as the DetachDirty flag is not there any more.   (detachCopy, detachCopyAll, serialization, commit if DetachAllOnCommit is true) - detached-clean                    -> detached-dirty   (persistent field modification) - detached-dirty                    -> detached-dirty   (persistent field modification) - detached-clean                    -> persistent-clean   (makePersistent) This will need to be a different test. - detached-dirty                    -> persistent-dirty   (makePersistent) Ditto. - hollow                            -> persistent-nontransactional-dirty   (persistent field modification) - persistent-nontransactional       -> persistent-nontransactional-dirty   (persistent field modification) - persistent-nontransactional-dirty -> persistent-nontransactional-dirty   (persistent field modification, rollback and RestoreValues is true) - persistent-nontransactional-dirty -> hollow   (commit and RetainValues is false, rollback and RestoreValues is false, evict, evictAll) - persistent-nontransactional-dirty -> persistent-nontransactional   (commit and RetainValues is true) Implementation hints: -------------------- Class org.apache.jdo.tck.lifecycle.StateTransitions maintains a matrix implementing all JDO lifecycle transitions. The lifecycle state transition algorithm works as follows: It iterates over all states and all operations. For each pair (state, operation) it creates an object, applies the operation to that object, and checks the actual state against the expected state. The transitions above may be implemented straight forward extending the available states, operations, and state transition matrix in classes StateTransitions and JDOTest (superclass). There is an issue related to operations makePersistent(detachedInstance) and detachCopy: These operations return objects having the new states. The object parameters retain their original states. Clearly, the states of the returned objects have to be checked. Have the states of the parameter objects to be checked also? Yes. I'd suggest writing a new test for the detach cases where you need to check multiple objects' life cycle changes. In the case of persistence by reachability, it might make sense to have a test that tests multiple objects. Assume an object graph where the name of the object reflects its state: detached1 refers to detached2  persistent1 is the result of makePersistent(detached1) and should have the same oid as detached1 persistent2 is referred to by persistent1 and should have the same oid as detached2 detached3 refers to transient4  persistent3 is the result of makePersistent(detached3) and should have the same oid as detached3 transient4 made a state change to persistent-new. Clearly this is a different style of test and probably should be a different test class (or at least a different test case) Other Questions: --------------- 1) If a persistent instance is detached, is the transitive closure of persistent instances detached implicitly? yes 2) If a detached instance is attached (makePersistent), is the transitive closure of detached instances attached implicitly? yes 3) If a detached instance is attached (makePersistent), is the transitive closure of transient instances made persistent implicitly? yes 4) There might be a typo in section 5.5.9 of the spec version (9/9/2005): "JDO instances that have been removed from their persistence manager and have fields marked as modified are detached." => "... and have fields marked as modified are detached-dirty." yes. Thanks, Craig Regards, Michael --  ------------------------------------------------------------------- Michael Watzek                  [EMAIL PROTECTED] Engineering GmbH mailto:[EMAIL PROTECTED]        Buelowstr. 66 Tel.:  ++49/30/235 520 36       10783 Berlin - Germany Fax.:  ++49/30/217 520 12       http://www.spree.de/ ------------------------------------------------------------------- Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp!

smime.p7s
Description: S/MIME cryptographic signature