OpenJPA
  1. OpenJPA
  2. OPENJPA-119

EntityManager.clear() should not implicitly invoke the flush operation

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 0.9.7
    • Component/s: jpa
    • Labels:
      None

      Description

      From the dev mailing list...

      =======================================
      We've noticed that when EntityManager.clear() is invoked, an implicit flush() is performed. Although the spec is cloudy in this area, I don't think this processing is correct. The javadoc is as follows for clear():

      /**

      • Clear the persistence context, causing all managed
      • entities to become detached. Changes made to entities that
      • have not been flushed to the database will not be
      • persisted.
        */
        public void clear();

      This indicates that Entities that have not been flushed will not be persisted. Thus, I would say this implies that we should not be doing an implicit flush. If the application wanted their Entities to be flushed before the clear, then they can call the flush() method before calling clear(). We shouldn't be doing this for them because then they have no choice.

      The Pro EJB3 Java Persistence API book has similar wording on pages 138-139:

      "..In many respects [clear] is semantically equivalent to a transaction rollback. All entity instances managed by the persistence context become detached with their state left exactly as it was when the clear() operation was invoked..."

      Our current processing for clear() eventually gets to this code:

      public void detachAll(OpCallbacks call) {
      beginOperation(true);
      try {
      if ((_flags & FLAG_FLUSH_REQUIRED) != 0)
      flush();
      detachAllInternal(call);
      } catch (OpenJPAException ke) {
      throw ke;
      } catch (RuntimeException re) {
      throw new GeneralException(re);
      } finally {
      endOperation();
      }
      }

      Basically, if we have dirtied the Persistence Context, then do a flush() followed by the detachAllInternal(). I don't think the clear() should be doing this flush() operation. Any disagreement?
      =======================================

      There was no disagreement, thus this JIRA issue.

        Activity

        Kevin Sutter created issue -
        Patrick Linskey made changes -
        Field Original Value New Value
        Description From the dev mailing list...

        =======================================
        We've noticed that when EntityManager.clear() is invoked, an implicit flush() is performed. Although the spec is cloudy in this area, I don't think this processing is correct. The javadoc is as follows for clear():

        /**
        * Clear the persistence context, causing all managed
        * entities to become detached. Changes made to entities that
        * have not been flushed to the database will not be
        * persisted.
        */
        public void clear();

        This indicates that Entities that have not been flushed will not be persisted. Thus, I would say this implies that we should not be doing an implicit flush. If the application wanted their Entities to be flushed before the clear, then they can call the flush() method before calling clear(). We shouldn't be doing this for them because then they have no choice.

        The Pro EJB3 Java Persistence API book has similar wording on pages 138-139:

        "..In many respects [clear] is semantically equivalent to a transaction rollback. All entity instances managed by the persistence context become detached with their state left exactly as it was when the clear() operation was invoked..."

        Our current processing for clear() eventually gets to this code:

            public void detachAll(OpCallbacks call) {
                beginOperation(true);
                try {
                    if ((_flags & FLAG_FLUSH_REQUIRED) != 0)
                        flush();
                    detachAllInternal(call);
                } catch (OpenJPAException ke) {
                    throw ke;
                } catch (RuntimeException re) {
                    throw new GeneralException(re);
                } finally {
                    endOperation();
                }
            }

        Basically, if we have dirtied the Persistence Context, then do a flush() followed by the detachAllInternal(). I don't think the clear() should be doing this flush() operation. Any disagreement?
        =======================================

        There was no disagreement, thus this JIRA issue.
        From the dev mailing list...

        =======================================
        We've noticed that when EntityManager.clear() is invoked, an implicit flush() is performed. Although the spec is cloudy in this area, I don't think this processing is correct. The javadoc is as follows for clear():

        /**
        * Clear the persistence context, causing all managed
        * entities to become detached. Changes made to entities that
        * have not been flushed to the database will not be
        * persisted.
        */
        public void clear();

        This indicates that Entities that have not been flushed will not be persisted. Thus, I would say this implies that we should not be doing an implicit flush. If the application wanted their Entities to be flushed before the clear, then they can call the flush() method before calling clear(). We shouldn't be doing this for them because then they have no choice.

        The Pro EJB3 Java Persistence API book has similar wording on pages 138-139:

        "..In many respects [clear] is semantically equivalent to a transaction rollback. All entity instances managed by the persistence context become detached with their state left exactly as it was when the clear() operation was invoked..."

        Our current processing for clear() eventually gets to this code:

        public void detachAll(OpCallbacks call) {
        beginOperation(true);
        try {
        if ((_flags & FLAG_FLUSH_REQUIRED) != 0)
        flush();
        detachAllInternal(call);
        } catch (OpenJPAException ke) {
        throw ke;
        } catch (RuntimeException re) {
        throw new GeneralException(re);
        } finally {
        endOperation();
        }
        }

        Basically, if we have dirtied the Persistence Context, then do a flush() followed by the detachAllInternal(). I don't think the clear() should be doing this flush() operation. Any disagreement?
        =======================================

        There was no disagreement, thus this JIRA issue.
        Kevin Sutter made changes -
        Status Open [ 1 ] Resolved [ 5 ]
        Resolution Fixed [ 1 ]
        Patrick Linskey made changes -
        Fix Version/s 0.9.7 [ 12312340 ]
        Kevin Sutter made changes -
        Status Resolved [ 5 ] Closed [ 6 ]

          People

          • Assignee:
            Kevin Sutter
            Reporter:
            Kevin Sutter
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development