db-jdo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Watzek <mwa.t...@spree.de>
Subject Proposal for JDO-258 and JDO-273
Date Tue, 17 Jan 2006 17:01:43 GMT

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
- detached-dirty                    -> persistent-dirty
- 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."

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/

View raw message