openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kevin Sutter (JIRA)" <j...@apache.org>
Subject [jira] Commented: (OPENJPA-119) EntityManager.clear() should not implicitly invoke the flush operation
Date Fri, 02 Feb 2007 20:50:05 GMT

    [ 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.


Mime
View raw message