JDO
  1. JDO
  2. JDO-347

JPOX fails some lifecycle tests

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: JDO 2 rc1
    • Fix Version/s: JDO 2 final (2.0)
    • Component/s: tck
    • Labels:
      None

      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.

        Activity

        Hide
        Martin Zaun added a comment -

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

        Show
        Martin Zaun added a comment - Attached error messages for failing tests lifecycle.StateTransitions (= state transitions of argument instances).
        Hide
        Martin Zaun added a comment -

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

        Show
        Martin Zaun added a comment - Attached error messages for failing test lifecycle.StateTransitionsReturnedObjects (= states of returned instances).
        Hide
        Andy Jefferson added a comment -

        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

        Show
        Andy Jefferson added a comment - 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
        Hide
        Andy Jefferson added a comment -

        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>

        Show
        Andy Jefferson added a comment - 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>
        Hide
        Craig L Russell added a comment -

        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.

        Show
        Craig L Russell added a comment - 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 .
        Hide
        Craig L Russell added a comment -

        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.

        Show
        Craig L Russell added a comment - 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.
        Hide
        Andy Jefferson added a comment -

        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.

        Show
        Andy Jefferson added a comment - 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.
        Hide
        Andy Jefferson added a comment -

        Test "StateTransitions" now passes with JPOX CVS

        Show
        Andy Jefferson added a comment - Test "StateTransitions" now passes with JPOX CVS
        Hide
        Andy Jefferson added a comment -

        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 ?

        Show
        Andy Jefferson added a comment - 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 ?
        Hide
        Craig L Russell added a comment -

        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.

        Show
        Craig L Russell added a comment - 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.
        Hide
        Andy Jefferson added a comment -

        Fixed in JPOX CVS

        Show
        Andy Jefferson added a comment - Fixed in JPOX CVS
        Hide
        Martin Zaun added a comment -

        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

        Show
        Martin Zaun added a comment - 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
        Hide
        Andy Jefferson added a comment -

        > 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

        Show
        Andy Jefferson added a comment - > 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
        Hide
        Martin Zaun added a comment -

        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.

        Show
        Martin Zaun added a comment - 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.
        Hide
        Andy Jefferson added a comment -

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

        Show
        Andy Jefferson added a comment - No problem Martin. It should all be built into the current JPOX nightly build and passes for me with latest SVN TCK

          People

          • Assignee:
            Andy Jefferson
            Reporter:
            Martin Zaun
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development