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 Re: Proposal for JDO-258 and JDO-273
Date Tue, 17 Jan 2006 21:18:23 GMT
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                  Tech@Spree Engineering GmbH
> mailto:mwa.tech@spree.de        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:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!


Mime
View raw message