db-jdo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Zaun <Martin.Z...@Sun.COM>
Subject spec questions on PM/Lifecycle after pm.close()
Date Wed, 08 Feb 2006 11:25:07 GMT

looking into JDO-238, some questions on the TCK ThreadSafe
test (the kind of exceptions thrown; the apparent need for
more than one barrier...) had me go back to the spec.

I have a couple of PM/Lifecycle-related questions (and some
comments on the PM.Multithreading section, which I'm sending
separately).  I've overlayed version jdo-2005-09-09.pdf with
the clarifications and amendments communicated by email since
then, but I'm not sure I've got them all and right.

1) State of managed instances after pm.close()?

I've tried to find the language in the spec relevant to this
- DetachOnClose, which is gone;
- 5.5.8 (Detached-clean) describes three transitions into
   this state, including the case for DetachAllOnCommit=true;
- 5.5.9 (Detached-dirty) describes two transitions into this
   state, including
     A5.5.9-AD1 [the instance is detached in the persistent-
     dirty state while the PersistenceManager flag DetachDirty
     is true;]
- 12.6.8 (Detaching and attaching instances) describes that
     In JDO 1.0, the behavior of persistent instances after
     closing the associated PersistenceManager is undefined.
     A12.6.8-1 [JDO 2 defines a new property called
     DetachAllOnCommit ...] which changes this behavior.

     DetachAllOnCommit=true: ... all detachable persistent
     instances in the cache transition to detached; non-
     detachable persistent instances transition to transient;

     DetachAllOnCommit=false: ... the state of persistent
     instances in the cache after commit is defined by the
     retainValues flag. A12.6.8-3

- Searching for 'DetachDirty' in the spec finds no other
   occurrences than in 5.5.9.  Obsolete?

- What's the case for DetachAllOnCommit=true and rollback?

- If DetachAllOnCommit=false, what can and cannot be done
   with non-transient and non-detached instances after
   pm.close() ?

I'm trying to infer an answer to the last question.  The
RetainValues flag decides whether the non-transient, non-
etached instances are persistent-nontransactional or hollow.
They clearly have to keep their StateManager references, for
instance, to have the interrogatives working.  They also
have to return a PM instance since they're not transient:

     PersistenceManager jdoGetPersistenceManager();
     A7.1-1 [This method returns the associated
     PersistenceManager] or A7.1-2 [null if the instance
     is transient.]


     A JDO instance is associated with either zero or one JDO
     PersistenceManager. A12.5-1 [It will be zero if and only
     if the JDO instance is in the transient or detached

It follows that they cannot be transfered to a different PM
instance via makePersistent(), deletePersistent() etc:

     void makePersistent (Object pc);
     A12.5.7-8 [They will throw a JDOUserException if the
     parameter instance is managed by a different

But also, those "dangling objects" cannot be made transient
or detached by their old, closed PM instance:

     A12.5-6 [After close completes, all methods on the
     PersistenceManager instance except isClosed(), close(),
     and get methods throw a JDOFatalUserException.]

Perhaps, this can be described as a consistent state: Those
PC methods which don't require an active transaction need to
continue to function; those which do would result in a
JDOFatalUserException (thrown by the closed, associated PM);
any attempt to move those instances to a different PM via
makePersistent() etc. would result in a JDOUserException.

But whether that interpretation is consistent or not, I'd
find it helpful if the spec addresses this case, even by
explicitely saying that the behaviour is undefined then.

2) Comment on closing of PMs

When taken literally, the assertion

     A12.5-6 [After close completes, all methods on the
     PersistenceManager instance except isClosed(), close(),
     and get methods throw a JDOFatalUserException.]

precludes any reusing and pooling of PMs.  The exception
should only be thrown while isClosed() returns true, as the
other assertion states

     A12.5-3 [The isClosed method returns false upon
     construction of the PersistenceManager instance], or
     A12.5-4 [upon retrieval of a PersistenceManager from a

However, given the above issue of "dangling instances" (non-
transient, non-detached) still pointing to an already closed
pm, I wonder if we have an issue when that closed pm becomes
reused again...

3) More cross-references between chapters 5, 7, and 12?

Since these three chapters are heavily interrelated, it
might be an idea to add cross-references, for instance, in
12.6 on PM.close() a reference to 12.6.8 and 5.5.8/9.


View raw message