[
https://issues.apache.org/jira/browse/OPENJPA-119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12469868
]
Kevin Sutter commented on OPENJPA-119:
--------------------------------------
Here's what I decided to do... I introduced a new boolean on the
detachAll(OpCallbacks, boolean) method, leaving the original
detachAll(OpCallbacks) as is. The original method now calls the new method
with a value of "true" so that the original processing takes place. I have
changed the EM.clear path so that it now calls the new method with a value of
"false" so that no flushing takes place. This seemed to be the least amount of
churn and still allow both types of flush/clear processing to take place.
I have decided not to introduce a new detachAll method on the
OpenJPAEntityManager interface at this time. I personally like to wait for a
need for modifying public interfaces, even if it's just for other products
extending OpenJPA.
I'll be dropping the changes shortly (after the testing checks out). I have
also added a testcase for this scenario.
Kevin
> EntityManager.clear() should not implicitly invoke the flush operation
> ----------------------------------------------------------------------
>
> Key: OPENJPA-119
> URL: https://issues.apache.org/jira/browse/OPENJPA-119
> Project: OpenJPA
> Issue Type: Bug
> Components: jpa
> Reporter: Kevin Sutter
> Assigned To: Kevin Sutter
>
> 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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
