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 <[EMAIL PROTECTED]> 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:[EMAIL PROTECTED]
P.S. A good JDO? O, Gasp!
