OpenJPA
  1. OpenJPA
  2. OPENJPA-1155

BrokerImpl.detachAllInternal() does not detach newly loaded entities

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 2.0.0
    • Fix Version/s: 2.0.0-M3
    • Component/s: kernel
    • Labels:
      None
    • Patch Info:
      Patch Available

      Description

      During detach, it is possible for additional entities to be loaded if the openjpa.DetachState property has been set to "all" or "fetch-groups". These entities may not be included in the collection of entities that are identified in the BrokerImpl.detachAllInternal() method when it calls the DetachManager.detachAll(collection) method. Before 2.0, these newly loaded entities were always detached since the detach processing always cascaded. However, with the 2.0 spec requirements for cascade, the default behavior no longer cascades. Therefore, there may be some entities left in the persistence context after this processing occurs. detachAllInternal() is associated with the clear(), close(), and afterCompletion() operations and it is expected that the persistence context really be empty. To ensure this, the compatibility option of cascadeWithDetach will be set to true by detachAllInternal() before calling the DetachManager.detach() method.

      1. patch2.txt
        1 kB
        Dianne Richards
      2. patch.txt
        0.9 kB
        Dianne Richards

        Activity

        Hide
        Dianne Richards added a comment -

        Attaching patch with the fix described in the previous comment.

        Show
        Dianne Richards added a comment - Attaching patch with the fix described in the previous comment.
        Hide
        Dianne Richards added a comment -

        I forgot to mention when I attached the patch - The original problem that caused this was in a container with a client-server application. I wasn't able to re-create this problem in a JSE environment, so I'm not able to provide junit tests.

        Show
        Dianne Richards added a comment - I forgot to mention when I attached the patch - The original problem that caused this was in a container with a client-server application. I wasn't able to re-create this problem in a JSE environment, so I'm not able to provide junit tests.
        Hide
        Jeremy Bauer added a comment -

        Comment on patch.txt dated 2009-07-02 08:56 AM:

        Resetting the compat flag should occur in a finally{} block. Otherwise, the detach mgr. could throw an exception and it the value would not get reset.

        Show
        Jeremy Bauer added a comment - Comment on patch.txt dated 2009-07-02 08:56 AM: Resetting the compat flag should occur in a finally{} block. Otherwise, the detach mgr. could throw an exception and it the value would not get reset.
        Hide
        Dianne Richards added a comment -

        Patch2 added with Jeremy's suggestion.

        Show
        Dianne Richards added a comment - Patch2 added with Jeremy's suggestion.
        Hide
        Jeremy Bauer added a comment -

        Committed patch2.txt for Dianne under revision 791568.

        Show
        Jeremy Bauer added a comment - Committed patch2.txt for Dianne under revision 791568.
        Hide
        Donald Woods added a comment -

        please open a new jira if additional work is required, as this is being marked as completed for the 2.0.0-M3 release

        Show
        Donald Woods added a comment - please open a new jira if additional work is required, as this is being marked as completed for the 2.0.0-M3 release

          People

          • Assignee:
            Dianne Richards
            Reporter:
            Dianne Richards
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development