castor
  1. castor
  2. CASTOR-1196

Objects loaded in different transactions can't be referenced in another long transaction.

    Details

    • Type: Bug Bug
    • Status: Closed Closed
    • Priority: Blocker Blocker
    • Resolution: Fixed
    • Affects Version/s: 0.9.7
    • Fix Version/s: 1.3 rc1
    • Component/s: JDO
    • Labels:
      None
    • Environment:
    • Testcase included:
      yes
    • Number of attachments :
      11

      Description

      Hi,

      I'm getting trouble with objects loaded in diferent long transactions, in short:

      //1st transaction
      db.begin();
      StateCountry state = db.load(StateCountry.class, "AASTCTPR");
      db.commit();
      ..

      //2nd transaction
      db.begin();
      Country country = db.load(Country.class, "AAAACTBR");
      db.commit();
      ...

      //3rd transaction
      state.setMyCountry(state);
      ..
      db.begin();
      db.update(state);
      db.commit();
      ..

      this trouble are same as reported in email:
      http://www.mail-archive.com/castor-user@exolab.org/msg00953.html

      I attached a test case, that output:

      [ClientAPP] populateData executed!
      [ClientAPP] 1st operation executed!
      [ClientAPP] StateCountry retrieved: ctf.jdo.tc0cw.StateCountry@19ce060

      { oid: 'AASTBRPR', name: 'PARANA', myCountry: 'AAAACTBR', timestamp: 1123762499887 }

      [ClientAPP] Country retrieved: ctf.jdo.tc0cw.Country@1359c1b

      { oid: 'AAAACTTS', name: 'COUNTRY FOR TEST', timestamp: 1123762499912 }

      [ClientAPP] 2nd operation executed!
      [ServerApp] fails with message: Nested error: org.exolab.castor.jdo.PersistenceException: Object, ctf.jdo.tc0cw.StateCountry@19ce060

      { oid: 'AASTBRPR', name: 'PARANA', myCountry: 'AAAACTTS', timestamp: 1123762499887 }

      , links to another object, ctf.jdo.tc0cw.Country@1359c1b

      { oid: 'AAAACTTS', name: 'COUNTRY FOR TEST', timestamp: 1123762499912 }

      that is not loaded/updated/created in this transaction: Object, ctf.jdo.tc0cw.StateCountry@19ce060

      { oid: 'AASTBRPR', name: 'PARANA', myCountry: 'AAAACTTS', timestamp: 1123762499887 }

      , links to another object, ctf.jdo.tc0cw.Country@1359c1b

      { oid: 'AAAACTTS', name: 'COUNTRY FOR TEST', timestamp: 1123762499912 }

      that is not loaded/updated/created in this transaction
      [ClientAPP] testRetrieveMany 3rd operation failed on server with message: Nested error: org.exolab.castor.jdo.PersistenceException: Object, ctf.jdo.tc0cw.StateCountry@19ce060

      { oid: 'AASTBRPR', name: 'PARANA', myCountry: 'AAAACTTS', timestamp: 1123762499887 }

      , links to another object, ctf.jdo.tc0cw.Country@1359c1b

      { oid: 'AAAACTTS', name: 'COUNTRY FOR TEST', timestamp: 1123762499912 }

      that is not loaded/updated/created in this transaction: Object, ctf.jdo.tc0cw.StateCountry@19ce060

      { oid: 'AASTBRPR', name: 'PARANA', myCountry: 'AAAACTTS', timestamp: 1123762499887 }

      , links to another object, ctf.jdo.tc0cw.Country@1359c1b

      { oid: 'AAAACTTS', name: 'COUNTRY FOR TEST', timestamp: 1123762499912 }

      that is not loaded/updated/created in this transaction
      [ClientAPP] Objects retrieved for delete: [ctf.jdo.tc0cw.StateCountry@164dbd5

      { oid: 'AASTBRPR', name: 'PARANA', myCountry: 'AAAACTBR', timestamp: 1123762499887 }

      , ctf.jdo.tc0cw.StateCountry@125844f

      { oid: 'AASTBRSP', name: 'SAO PAULO', myCountry: 'AAAACTBR', timestamp: 1123762499897 }

      , ctf.jdo.tc0cw.Country@9cb0f4

      { oid: 'AAAACTBR', name: 'BRAZIL', timestamp: 1123762499879 }

      , ctf.jdo.tc0cw.StateCountry@11978b

      { oid: 'AASTUSTX', name: 'TEXAS', myCountry: 'AAAACTUS', timestamp: 1123762499904 }

      , ctf.jdo.tc0cw.StateCountry@26dbec

      { oid: 'AASTUSCL', name: 'COLORADO', myCountry: 'AAAACTUS', timestamp: 1123762499909 }

      , ctf.jdo.tc0cw.Country@f42ad0

      { oid: 'AAAACTUS', name: 'UNITED STATES', timestamp: 1123762499900 }

      , ctf.jdo.tc0cw.Country@1309e87

      { oid: 'AAAACTTS', name: 'COUNTRY FOR TEST', timestamp: 1123762499912 }

      ]
      [ServerApp] fails with message: The object of type ctf.jdo.tc0cw.StateCountry is not persistent – it was not queried or created within this transaction
      [ClientAPP] removeData delete operation failed on server with message: The object of type ctf.jdo.tc0cw.StateCountry is not persistent – it was not queried or created within this transaction

      //end of output

      Note that this trouble occurs for update and delete.

      1. patch-C1196-20050811.txt
        24 kB
        Clovis Wichoski
      2. patch-C1196-20050815.txt
        26 kB
        Clovis Wichoski
      3. patch-C1196-20050816.txt
        28 kB
        Clovis Wichoski
      4. patch-C1196-20050817.txt
        30 kB
        Clovis Wichoski
      5. patch-C1196-20050819.txt
        33 kB
        Clovis Wichoski
      6. patch-C1196-20050820.txt
        36 kB
        Ralf Joachim
      7. patch-C1196-20050826.txt
        55 kB
        Clovis Wichoski
      8. patch-C1196-20050901.txt
        55 kB
        Ralf Joachim
      9. patch-C1196-20050912.txt
        40 kB
        Clovis Wichoski
      10. patch-C1196-20050913.txt
        45 kB
        Ralf Joachim
      11. patch-C1196-20080923.txt
        37 kB
        Ralf Joachim

        Issue Links

          Activity

          Hide
          Ralf Joachim added a comment -

          to 1) at your application you may set whatever constraint you like but should also take into account that some can prevent records to be deleted at all. If you have set such constraints it will also be imposible for castor to delete them. As our test cases need to be executed multiple times without creating a new database such constraints are not acceptable here. E.g. there had been no way to delete an order or orderItem with the constraints you have set. Having said that there also may be combinations of constraints that would allow to delete records with SQL statements but castor can not handle.

          to 2) i suggest the following order for your test:
          1. remove table entries with passthrough SQL statments not throwing excdeptions when tables are empty
          2. create your test data
          3. execute update tests
          4. remove your test data (the remove method as it currently is)
          With this you always have the same test conditions even if something fails at steps 2, 3 or 4. If you like to see data in tables you may comment to execute step 4.

          3) to 5) I do not understand that

          Show
          Ralf Joachim added a comment - to 1) at your application you may set whatever constraint you like but should also take into account that some can prevent records to be deleted at all. If you have set such constraints it will also be imposible for castor to delete them. As our test cases need to be executed multiple times without creating a new database such constraints are not acceptable here. E.g. there had been no way to delete an order or orderItem with the constraints you have set. Having said that there also may be combinations of constraints that would allow to delete records with SQL statements but castor can not handle. to 2) i suggest the following order for your test: 1. remove table entries with passthrough SQL statments not throwing excdeptions when tables are empty 2. create your test data 3. execute update tests 4. remove your test data (the remove method as it currently is) With this you always have the same test conditions even if something fails at steps 2, 3 or 4. If you like to see data in tables you may comment to execute step 4. 3) to 5) I do not understand that
          Hide
          Clovis Wichoski added a comment -

          added a new patch, with new idea now only changes few lines of org.castor.persist.resolver.PersistanceCapableRelationResolver and testCase pass.

          All CTF tests pass too.

          for me with this new patch this issue can be closed, werner, ralf, what you think?

          notes about questions above:
          the question 1) is maybe a trouble of design or deploy, and dont for castor, then dont be needed anymore.
          for question 2) the order of testCases are correct now.
          This patch solves question 3) and 4), since the way that autoload has changed, autoload only when user call commit.
          for 5) old patchs maybe interesting to be checked for what ClassMolder must be loaded based on Class of value.

          Show
          Clovis Wichoski added a comment - added a new patch, with new idea now only changes few lines of org.castor.persist.resolver.PersistanceCapableRelationResolver and testCase pass. All CTF tests pass too. for me with this new patch this issue can be closed, werner, ralf, what you think? notes about questions above: the question 1) is maybe a trouble of design or deploy, and dont for castor, then dont be needed anymore. for question 2) the order of testCases are correct now. This patch solves question 3) and 4), since the way that autoload has changed, autoload only when user call commit. for 5) old patchs maybe interesting to be checked for what ClassMolder must be loaded based on Class of value.
          Hide
          Ralf Joachim added a comment -

          Updated patch fixing some problems at testcase.

          Show
          Ralf Joachim added a comment - Updated patch fixing some problems at testcase.
          Hide
          Ralf Joachim added a comment -

          Final patch with test case integrated into cpa test suite. Every test of cpa passes.

          Show
          Ralf Joachim added a comment - Final patch with test case integrated into cpa test suite. Every test of cpa passes.
          Hide
          Ralf Joachim added a comment -

          Reopend to change component.

          Show
          Ralf Joachim added a comment - Reopend to change component.

            People

            • Assignee:
              Ralf Joachim
              Reporter:
              Clovis Wichoski
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Time Tracking

                Estimated:
                Original Estimate - Not Specified
                Not Specified
                Remaining:
                Remaining Estimate - 0 minutes
                0m
                Logged:
                Time Spent - 5 hours, 20 minutes
                5h 20m