You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openjpa.apache.org by Kevin Sutter <kw...@gmail.com> on 2007/01/30 23:32:04 UTC
EntityManager.clear() semantics
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
Re: EntityManager.clear() semantics
Posted by Craig L Russell <Cr...@Sun.COM>.
So, officially, no new test cases are allowed to be introduced except
via the JCP Change Review process that results in an updated version
of the spec, RI, and TCK. So it's a fairly grand scale process for
something as massive as Java EE 5.
It's a lot less effort to "simply" update the JSR 220 specification
but they might be thinking "need to update the entire JSR 243 stack"
for this change.
Craig
On Feb 6, 2007, at 6:03 AM, Kevin Sutter wrote:
> Thanks, Craig. I also asked our CTS rep to present this new
> testcase, but I
> haven't heard what the result is. I did find out that they
> normally do not
> introduce new tests during a test cycle (ie. Java EE 5). They only
> remove
> testcases based on successful challenges. But, they will take note
> of new
> test requests and possibly include them in the next round. That's
> what our
> experience has been anyway.
>
> Kevin
>
> On 2/5/07, Craig L Russell <Cr...@sun.com> wrote:
>>
>> 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 <Cr...@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!
>>
>>
>>
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!
Re: EntityManager.clear() semantics
Posted by Kevin Sutter <kw...@gmail.com>.
Thanks, Craig. I also asked our CTS rep to present this new testcase, but I
haven't heard what the result is. I did find out that they normally do not
introduce new tests during a test cycle (ie. Java EE 5). They only remove
testcases based on successful challenges. But, they will take note of new
test requests and possibly include them in the next round. That's what our
experience has been anyway.
Kevin
On 2/5/07, Craig L Russell <Cr...@sun.com> wrote:
>
> 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 <Cr...@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!
>
>
>
Re: EntityManager.clear() semantics
Posted by Craig L Russell <Cr...@Sun.COM>.
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 <Cr...@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!
Re: EntityManager.clear() semantics
Posted by Kevin Sutter <kw...@gmail.com>.
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 <Cr...@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!
>
>
>
>
Re: EntityManager.clear() semantics
Posted by Craig L Russell <Cr...@Sun.COM>.
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!
Re: EntityManager.clear() semantics
Posted by Kevin Sutter <kw...@gmail.com>.
Understood, Abe. I just wanted to get some agreement with you and/or
Patrick before pursuing this type of change. Thanks!
Kevin
On 1/31/07, Abe White <aw...@bea.com> wrote:
>
> > 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?
>
> I agree. But note that just removing the flush call won't work for a
> couple of reasons: it's needed by JDO, and we'll just flush later in
> the DetachManager when we detect a dirty instance. So just a warning
> that it isn't quite as trivial a fix as it might appear to be.
> _______________________________________________________________________
> Notice: This email message, together with any attachments, may contain
> information of BEA Systems, Inc., its subsidiaries and affiliated
> entities, that may be confidential, proprietary, copyrighted and/or
> legally privileged, and is intended solely for the use of the individual
> or entity named in this message. If you are not the intended recipient,
> and have received this message in error, please immediately return this
> by email and then delete it.
>
Re: EntityManager.clear() semantics
Posted by Abe White <aw...@bea.com>.
> 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?
I agree. But note that just removing the flush call won't work for a
couple of reasons: it's needed by JDO, and we'll just flush later in
the DetachManager when we detect a dirty instance. So just a warning
that it isn't quite as trivial a fix as it might appear to be.
_______________________________________________________________________
Notice: This email message, together with any attachments, may contain
information of BEA Systems, Inc., its subsidiaries and affiliated
entities, that may be confidential, proprietary, copyrighted and/or
legally privileged, and is intended solely for the use of the individual
or entity named in this message. If you are not the intended recipient,
and have received this message in error, please immediately return this
by email and then delete it.