JPOX fails some lifecycle tests

• Key: JDO-347
• Type: Bug
• Status: Resolved
• Resolution: Fixed
• Priority: Major
• Assignee: Andy Jefferson
• Reporter: Martin Zaun
• Component/s: tck2
• Affects Version/s: JDO 2 rc1
• Fix Version/s: JDO 2 final

Description

The integration of fixes for JDO-273 and JDO-258 has added (and fixed) a number of lifecycle test cases that are
failed by JPOX. See attached error messages.

Comments

[Martin Zaun]

Attached error messages for failing tests lifecycle.StateTransitions (= state transitions of argument instances).

[Martin Zaun]

Attached error messages for failing test lifecycle.StateTransitionsReturnedObjects (= states of returned instances).

[Andy Jefferson]

For information : JPOX CVS cuts the long list of failing transitions attached to this issue down to

    [java] Assertions A5.9-1 through A5.9-190 (StateTransitions) failed:
    [java] StateTransitions: optimistic transaction; current state hollow
    [java] makeTransient; unexpected exception caught: java.lang.ClassCastException

    [java] Assertions A5.9-1 through A5.9-190 (StateTransitions) failed:
    [java] StateTransitions: optimistic transaction; current state hollow
    [java] serialize with active tx transitioned instance to invalid state hollow; expected state persistent-clean

    [java] Assertions A5.9-1 through A5.9-190 (StateTransitions) failed:
    [java] StateTransitions: optimistic transaction; current state persistent-nontransactional
    [java] serialize with active tx transitioned instance to invalid state hollow; expected state persistent-clean

[Andy Jefferson]

org.apache.jdo.tck.lifecycle.StateTransitionsReturnedObjects :-
This test seems to think that calling detachCopy on a detached instance will return a DETACH_CLEAN.
I personally would defer to 12.6.8 "Explicit Detachment" of the JDO2 spec
<spec>If the parameter instance (to detachCopy) is detached, then JDOUserException is thrown.</spec>

[Craig Russell]

This is an inconsistency in the spec. The spec also says that the reachability algorithm is run on the graph of instances and this will cause detached instances to be attached. Then the cached instance is returned.

I've made a note about this in the errata for the spec at http://wiki.apache.org/jdo/ChangeLog.

[Craig Russell]

It might be useful here to review the process of detachCopy.

First, the instances in the parameter list are made persistent as if makePersistent had been called. This will recursively make detached and transient instances persistent (detached instances are replaced in this process by corresponding persistent instances).

Second, the FetchPlan is used to instantiate the object graph.

Third, the detached instance graph is created from the persistent object graph, using the FetchPlan to determine which fields are to be marked as loaded in the detached instance graph.

The detached instances corresponding to persistent instances by position in the original parameter list are returned to the user.

So the test case that calls detachCopy on a detached instance expects that the instance returned is a newly created detached instance with the same object id as the persistent instance in the cache and the parameter instance.

[Andy Jefferson]

I would like to know what the StateTransitionsReturnedObjects tests are performing. They state errors like
    [java] Assertions A5.9-1 through A5.5.8 (serialization, detachment, attachment) failed:
    [java] StateTransitionsReturnedObjects: datastore transaction; current state transient-clean
    [java] serialize with active tx returned instance in invalid state detached-clean; expected state transient

What is the "serialization, detachment, attachment" part of the message ?
Is it that a "transient-clean" has been serialised, then detached, then attached and it ends up with "detached-clean" instead of expected "transient" ?
Dumping all tests into one JUnit means that it is time consuming to debug such things, particularly in terms of locating the relevant part in the JPOX log.

[Andy Jefferson]

Test "StateTransitions" now passes with JPOX CVS

[Andy Jefferson]

I would like some input into StateTransitionsReturnedObjects. Let's take this message :-

    [java] Assertions A5.9-1 through A5.5.8 (serialization, detachment, attachment) failed:
    [java] StateTransitionsReturnedObjects: datastore transaction; current state transient-clean
    [java] serialize with active tx returned instance in invalid state detached-clean; expected state transient

Looking at the test it takes a transient-clean instance (in a txn) and serialises it and then deserialises the serialised object. The end result object will have the detached state present and no StateManager. Consequently it will be detached. Why is the expectation "transient" ? What am I missing ? ;-)

[Craig Russell]

The transient clean state is not persistent. It has no object id. When it's serialized, it should have no detached state. When jdoPreSerialize is executed, the StateManager should not create a detached state. When the instance is deserialized, it should still have no detached state. Unlike detachCopy, which makes the object graph persistent, serialize doesn't make transient instances persistent.

[Andy Jefferson]

Fixed in JPOX CVS

[Martin Zaun]

With the latest integration of a fix for JDO-273, there's one lifecycle test failing: serialize with
optimistic tx should leave the state unchanged (in contrast to a datastore tx, where serialize
transitions hollow/persistent-nontransactional to persistent-clean).

UNCHANGED should be the state transition for
1) test(org.apache.jdo.tck.lifecycle.StateTransitions)junit.framework.AssertionFailedError:
Assertions A5.9-1 through A5.9-190 (StateTransitions) failed:
StateTransitions: optimistic transaction; current state hollow
serialize with active optimistic tx transitioned instance to invalid state persistent-clean; expected state hollow
Assertions A5.9-1 through A5.9-190 (StateTransitions) failed:
StateTransitions: optimistic transaction; current state persistent-nontransactional
serialize with active optimistic tx transitioned instance to invalid state persistent-clean; expected state persistent-nontransactional

[Andy Jefferson]

> With the latest integration of a fix for JDO-273, there's one lifecycle test failing: serialize with
> optimistic tx should leave the state unchanged (in contrast to a datastore tx, where serialize
> transitions hollow/persistent-nontransactional to persistent-clean).

Great. That's what it used to do until 3 days ago when I changed it to match the test! Will change it back again

[Martin Zaun]

Sorry if that case has caused additional work. JDO-273 had a comment that this case
(serialize with active tx) needs review, but we wanted to get the new tests commited
last week.

[Andy Jefferson]

No problem Martin. It should all be built into the current JPOX nightly build and passes for me with latest SVN TCK