OpenJPA
  1. OpenJPA
  2. OPENJPA-568

Delete, re-insert and setting relationship in the same transaction results in

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 1.1.0
    • Fix Version/s: 1.1.0
    • Component/s: kernel
    • Labels:
      None
    • Environment:

      Description

      The test deletes and instance and creates another with the same primary keys and encounters an exception while making the new one persistent.

      Here is the snippet from the test code:

      pm.currentTransaction().begin();
      MappingTest2 test2c = new MappingTest2();
      test2c.setPk1(test2b.getPk1());
      test2c.setPk2(test2b.getPk2());
      pm.deletePersistent(test2b);

      test4.getNManyMap().put("key2", test2);
      test4.getManyManyMap().remove(test2b);
      test4.getManyManyMap().put(test2, test2);
      pm.makePersistent(test2c);
      test4.setInverseOneOne(test2c);

      MappingTest4 test4c = new MappingTest4();
      test4c.setInverseOwnerOneOne(test2c);
      test2c.setOneOneOwner(test4c);
      pm.makePersistent(test4c);
      pm.currentTransaction().commit();

      The problem with this issue was that the JDO PersistenceManager. makePersistent() is failing with the following exception:

      [testlogic] <openjpa-1.1.0-SNAPSHOT-r420667:634150 nonfatal user error>
      kodo.jdo.UserException: Operation attempted on a deleted instance.
      [testlogic] FailedObject: kodo.jdbc.meta.MappingTest2-3::4
      [testlogic] at org.apache.openjpa.kernel.PCState.error(PCState.java:443)
      [testlogic] at
      org.apache.openjpa.kernel.PDeletedState.beforeOptimisticWrite(PDeletedState.java:76)
      [testlogic] at
      org.apache.openjpa.kernel.StateManagerImpl.dirty(StateManagerImpl.java:1571)
      [testlogic] at
      org.apache.openjpa.kernel.StateManagerImpl.settingObjectField(StateManagerImpl.java:1898)
      [testlogic] at
      org.apache.openjpa.kernel.AttachStrategy.attachField(AttachStrategy.java:204)
      [testlogic] at
      org.apache.openjpa.kernel.VersionAttachStrategy.attach(VersionAttachStrategy.java:164)
      [testlogic] at
      org.apache.openjpa.kernel.AttachManager.attach(AttachManager.java:241)
      [testlogic] at
      org.apache.openjpa.kernel.VersionAttachStrategy.attachInPlace(VersionAttachStrategy.java:267)
      [testlogic] at
      org.apache.openjpa.kernel.VersionAttachStrategy.attachFieldsInPlace(VersionAttachStrategy.java:218)
      [testlogic] at
      org.apache.openjpa.kernel.VersionAttachStrategy.attach(VersionAttachStrategy.java:133)
      [testlogic] at
      org.apache.openjpa.kernel.AttachManager.attach(AttachManager.java:241)
      [testlogic] at
      org.apache.openjpa.kernel.AttachManager.attach(AttachManager.java:101)
      [testlogic] at
      org.apache.openjpa.kernel.BrokerImpl.attach(BrokerImpl.java:3191)
      [testlogic] at kodo.kernel.KodoBroker.attach(KodoBroker.java:251)
      [testlogic] at
      org.apache.openjpa.kernel.DelegatingBroker.attach(DelegatingBroker.java:1142)
      [testlogic] at
      kodo.jdo.PersistenceManagerImpl.makePersistent(PersistenceManagerImpl.java:496)
      [testlogic] at
      kodo.jdbc.kernel.TestFlush.testDeleteAndReInsert(TestFlush.java:124)

      Synopsis:

      When the second call to pm.makePersistent(test2c) is made it is not attached correctly. The effect of the prior pm.deletePersistent(test2b) which deletes the object with the same key is kept in the persistence context and hence when a relation is established with the deleted entity the third pm.makePersistent(test4c) call throws the above exception.

      The fix that I have is to correct the logic in the org.apache.openjpa.kernel.VersionAttachStrategy.attach() method where it tries to make a determination of whether this is a new object by also checking whether the existing entity is deleted or not. And that fixes the problem. I will attach it as a patch shortly.

      Thanks

      Sandeep

        Activity

        Hide
        Sandeep Shrivastava added a comment -

        The fix to the VersionAttachStrategy class that addresses this issue.

        Show
        Sandeep Shrivastava added a comment - The fix to the VersionAttachStrategy class that addresses this issue.
        Hide
        Abe White added a comment -

        As of revision 646082, I believe this patch is invalid. The patch was to fix some of the side effects of the original 245 fix, but this revision redid the 245 fix in a manner that eliminated the offending side effects.

        My hunch is that the test mentioned in this report will now pass even without this patch. There are some esoteric configurations, though (like detached state being disabled) where a test like this might still fail. I believe the proper fix is to amend BrokerImpl.isDetached(Object) to pass the OID_NODELETED flag when it makes its call to find(...).

        Show
        Abe White added a comment - As of revision 646082, I believe this patch is invalid. The patch was to fix some of the side effects of the original 245 fix, but this revision redid the 245 fix in a manner that eliminated the offending side effects. My hunch is that the test mentioned in this report will now pass even without this patch. There are some esoteric configurations, though (like detached state being disabled) where a test like this might still fail. I believe the proper fix is to amend BrokerImpl.isDetached(Object) to pass the OID_NODELETED flag when it makes its call to find(...).
        Hide
        Sandeep Shrivastava added a comment -

        This problem is resolved by the prior fixes at change 646082.

        Show
        Sandeep Shrivastava added a comment - This problem is resolved by the prior fixes at change 646082.

          People

          • Assignee:
            Unassigned
            Reporter:
            Sandeep Shrivastava
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Time Tracking

              Estimated:
              Original Estimate - 24h
              24h
              Remaining:
              Remaining Estimate - 24h
              24h
              Logged:
              Time Spent - Not Specified
              Not Specified

                Development