Craig,
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
case:
- 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
Questions:
- 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.]
and
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
state.]
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
PersistenceManager.]
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
pool].
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.
Thanks,
Martin
