You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jdo-dev@db.apache.org by Michael Watzek <mw...@spree.de> on 2006/01/17 18:01:43 UTC
Proposal for JDO-258 and JDO-273
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
(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)
- detached-dirty -> persistent-dirty
(makePersistent)
- 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?
Other Questions:
---------------
1) If a persistent instance is detached, is the transitive closure of
persistent instances detached implicitely?
2) If a detached instance is attached (makePersistent), is the
transitive closure of detached instances attached implicitely?
3) If a detached instance is attached (makePersistent), is the
transitive closure of transient instances made persistent implicitely?
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."
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/
-------------------------------------------------------------------
Re: Proposal for JDO-258 and JDO-273
Posted by Craig L Russell <Cr...@Sun.COM>.
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!