openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Craig L Russell <Craig.Russ...@Sun.COM>
Subject Re: EntityManager.clear() semantics
Date Mon, 05 Feb 2007 23:28:51 GMT
I've forwarded the new test case to our CTS team here. They will take  
a look to see if it can be adapted to the CTS test framework.

Craig

On Jan 31, 2007, at 6:25 AM, Kevin Sutter wrote:

> Craig,
> If anybody would have a channel to the CTS team, I would think it  
> would be
> you.  :-)  I have also passed on this request to our CTS rep to see  
> where it
> takes us.  Good idea. Thanks.
>
> Kevin
>
> On 1/30/07, Craig L Russell <Craig.Russell@sun.com> wrote:
>>
>> Hi Kevin,
>>
>> I agree with your analysis.
>>
>> I would also like to see a CTS test made for this case. Do we have a
>> channel through BEA or IBM for requests for CTS test cases?
>>
>> Another recent example is the EntityManager.getDelegate behavior
>> which surely should be a candidate for a CTS test.
>>
>> Craig
>>
>> On Jan 30, 2007, at 2:32 PM, Kevin Sutter wrote:
>>
>> > Hi,
>> > 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?
>> >
>> > Thanks,
>> > Kevin
>>
>> Craig Russell
>> Architect, Sun Java Enterprise System http://java.sun.com/products/ 
>> jdo
>> 408 276-5638 mailto:Craig.Russell@sun.com
>> P.S. A good JDO? O, Gasp!
>>
>>
>>
>>

Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!


Mime
View raw message