Details

    • Type: Bug
    • Status: Closed
    • Priority: Critical
    • Resolution: Fixed
    • Affects Version/s: 2.2.0
    • Fix Version/s: 2.4.0
    • Component/s: kernel
    • Labels:
      None

      Description

      When there are two objects in OneToMany relation and when One sets Many and vice versa the filed Many.one became null. It seems to be related with code added in this issue https://issues.apache.org/jira/browse/OPENJPA-2006. To reproduce: https://github.com/dogenkigen/OpenJPA-bug

        Activity

        Hide
        curtisr7 Rick Curtis added a comment -

        I haven't been able to quite figure this one out, but it looks like there is a bug between the runtime flush logic and the InverseManager trying to 'fix-up' relationships. As a work around, you could manage your own relationships rather than relying on the runtime to do it for you?

        ie: Remove <property name="openjpa.InverseManager" value="true" /> from your p.xml file.

        Show
        curtisr7 Rick Curtis added a comment - I haven't been able to quite figure this one out, but it looks like there is a bug between the runtime flush logic and the InverseManager trying to 'fix-up' relationships. As a work around, you could manage your own relationships rather than relying on the runtime to do it for you? ie: Remove <property name="openjpa.InverseManager" value="true" /> from your p.xml file.
        Hide
        mlaskows Maciej Laskowski added a comment - - edited

        It could be work around if the application have only few relations, but in my system I have hundreds of them.

        Show
        mlaskows Maciej Laskowski added a comment - - edited It could be work around if the application have only few relations, but in my system I have hundreds of them.
        Hide
        struberg Mark Struberg added a comment -

        I've pretty much hit the same issue.
        From debugging into it seems that the StateManager#fetchObjectField resets the internally stored value to null after the method gets used.
        As the InversManager relies on this field it 'trashes' the later 'normal' usage.

        The comment which were on the code seems to indicate that this used to create mem leaks a very long time ago:

        // don't hold onto strong ref to object

        This is really ancient code but from what I've seen we can really remove this reset.

        Show
        struberg Mark Struberg added a comment - I've pretty much hit the same issue. From debugging into it seems that the StateManager#fetchObjectField resets the internally stored value to null after the method gets used. As the InversManager relies on this field it 'trashes' the later 'normal' usage. The comment which were on the code seems to indicate that this used to create mem leaks a very long time ago: // don't hold onto strong ref to object This is really ancient code but from what I've seen we can really remove this reset.
        Hide
        jira-bot ASF subversion and git services added a comment -

        Commit 1674148 from Mark Struberg in branch 'openjpa/trunk'
        [ https://svn.apache.org/r1674148 ]

        OPENJPA-2287 do not clear object fields for fetchObjectField

        • Other objects do not get cleared neither.
        • The code dates from JDO times and I've asked a few people and no one had an explanation for it
        • It introduces nullpointer exceptions in cases where we have to navigate over the field a few times. E.g. in complex scenarios.
        Show
        jira-bot ASF subversion and git services added a comment - Commit 1674148 from Mark Struberg in branch 'openjpa/trunk' [ https://svn.apache.org/r1674148 ] OPENJPA-2287 do not clear object fields for fetchObjectField Other objects do not get cleared neither. The code dates from JDO times and I've asked a few people and no one had an explanation for it It introduces nullpointer exceptions in cases where we have to navigate over the field a few times. E.g. in complex scenarios.

          People

          • Assignee:
            struberg Mark Struberg
            Reporter:
            mlaskows Maciej Laskowski
          • Votes:
            1 Vote for this issue
            Watchers:
            4 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development