Re: EntityManager.clear() semantics

[Craig L Russell]

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,

takes us.  Good idea. Thanks.

Kevin

On 1/30/07, Craig L Russell <[EMAIL PROTECTED]> wrote:

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

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,

> 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

> 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

> We've noticed that when EntityManager.clear() is invoked, an implicit > before the clear, then they can call the flush() method before calling Architect, Sun Java Enterprise System http://java.sun.com/products/ jdo

408 276-5638 mailto:[EMAIL PROTECTED]
P.S. A good JDO? O, Gasp!

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

smime.p7s
Description: S/MIME cryptographic signature