[
https://issues.apache.org/jira/browse/OPENJPA-119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12469556
]
Kevin Sutter commented on OPENJPA-119:
--------------------------------------
Contrary to Abe's comments in the dev mailing list, this problem may easily be
resolved by just removing the conditional and flush() invocation from the
detachAll() method.
After analyzing this further, the detachAllInternal() invocation eventually
creates a DetachManager passing in "true" as the second parameter on the
constructor. This "true" parameter indicates that any flushing has already
been processed, as the following javadoc indicates:
* @param full whether the entire broker cache is being detached; if
* this is the case, we assume the broker has already
* flushed if needed, and that we're detaching in-place
Thus, when we get to the detachInternal method on the DetachManager, the
_flushed flag is already set to true and no more flushing is performed.
So, by removing the flush() processing in the detachAll() method on BrokerImpl,
it seems to resolve the problem.
Abe had indicated that we still might need this flush processing for JDO. But,
since I don't know how JDO is using the kernel, it's kind of difficult for me
to determine how to make this work for both cases -- since I don't know the
code paths that JDO follows. So, my take is that I will fix the problem for
the JPA clear() processing. If this causes a problem with other usages of the
kernel, then somebody more familiar with that usage may need to further adjust
the code.
Fair? Or, am I missing something?
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.
