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

[ Post a follow-up to this message ]

[ Post a follow-up to this message ]