Re: [eclipselink-users] Bizarre constraint violation

[Noah White <emailnbw@xxxxxxxxx>]

After more investigation I’ve been able to narrow down the code path that will trigger the constraint violation to this:

    @PersistenceContext(unitName = “Bizzaro”)

    private EntityManager entityMgr;

    @EJB

    FooBean fooBean;

    public void someBizMethod() {

        Request myRequest = entityMgr.find(Request.class, 123);

        fooBean.removeByName(myRequest.getName());

    }

Inside FooBean (which is a SSB w/injected PU) removeByName is a CMT method which looks up Foo with a TypedQuery and then calls entityMgr.remove(foo); So something like this:

    Foo myFoo = query.getSingleResult();

    entityMgr.remove(myFoo);

    entityMgr.flush();  <— Explicit flush because I want to ensure this delete is ordered before subsequent recreate - triggers the constraint violation mentioned below

So now for the kicker. I thought, ok lets experiment and explicitly clear the entity manager in between the lookup of myRequest and the lookup/removal of myFoo so the flush shouldn’t be sending anything related to myRequest as it’s been cleared. So I tried that and low and behold I am getting the same results.  

Foo does not contain a Request so how, after clearing the entity manager and in theory detaching myRequest, is a referential constraint between it and a BazFile object tripped?!

-Noah

On Sep 22, 2014, at 5:22 PM, Laird Nelson <ljnelson@xxxxxxxxx> wrote:

That's interesting.  You know, yes—some people don't—that the act of retrieving an object puts it in the persistence context?  So if there's any modification to Request it will be "sent down" to the database, even if naively you thought you were just doing a query.  I'm guessing you know this already but many of my teams over time have been burned by this.

Best,

Laird

On Mon, Sep 22, 2014 at 2:13 PM, Noah White <emailnbw@xxxxxxxxx> wrote:

I’m dealing with EJB 3.1 SSBs which inject a JTA PersistenceContext.  In one of them is a method which is annotated to require a new transaction. Inside that method the code looks up an entity of type Request, then it deletes an entity of type Foo, and then it attempts to create a new entity of type Foo. In the process of creating this new entity of type Foo it performs a named typed query against an entity of Type Bar (eg. SELECT b FROM Bar WHERE b.name=:name).  When the code calls query.getResultSet() and exception is thrown which references a constraint violation on an entity of type Request. Specifically:

java.sql.SQLIntegrityConstraintViolationException: ORA-02292: integrity constraint (MYDB.REQUEST_FILE_NUMBER) violated - child record found.

From the stack trace its being triggered by the entity manager performing a pre query flush.  The constraint involved is for referential integrity between a Request and a File. The Request object has an optional 1-to-1 unidirectional relationship with File and the constraint is there to ensure the referenced file exists. In this case the Request has a null value for the its File property which should be OK given this is an optional relationship.  A Request is not being merged or persisted it was simply looked up at the start of the TX.

I’m baffled as to why this is being thrown.  Any thoughts are appreciated.

Thanks,

-Noah

_______________________________________________
eclipselink-users mailing list
eclipselink-users@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/eclipselink-users

--
http://about.me/lairdnelson