[ 
https://issues.apache.org/jira/browse/OPENJPA-119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12469562
 ] 

Abe White commented on OPENJPA-119:
-----------------------------------

"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"

JDO needs to flush when detachAll() is called.  JPA doesn't.  Rather than 
changing the code out from under JDO, how about adding a boolean to the method. 
 At least then JDO code (and theoretically any other code using the method) 
will fail to compile.  That will allow us (and theoretically anyone else) to 
see the incompatibility and update our code, rather than having our detach 
behavior suddenly become incorrect.  If we later discover a better way to do 
it, we can remove the boolean and fix the compile-time problems that will again 
result -- I'd much rather be getting compile time errors that I'm forced to fix 
than to have to debug why an obscure unit test or user case suddenly stops 
working at a later date.

In fact given the new (and correct) clear() behavior, I think we should add an 
OpenJPAEntityManager.detachAll() method that retains the old behavior, because 
it is actually useful in some cases.  So the EntityManagerImpl would end up 
using Broker.detachAll with both "true" and "false" flush flags.

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

Reply via email to