RE: [eclipselink-users] SQL emitted by EclipseLink is searchingforan obj

["Gschwind, Doug" <Doug.Gschwind@xxxxxxxxxxxxxx>]

Morning James,

The Visit class bears the @OptimisticLocking(cascade=true) annotation,
and we get the same statement executed if the cascade attribute is
instead set to false. Also, the ManyToOne back reference from Service to
Visit has been set.

I have created EclipseLink defect 264406 per your request.

Thanks,

Doug

-----Original Message-----
From: eclipselink-users-bounces@xxxxxxxxxxx
[mailto:eclipselink-users-bounces@xxxxxxxxxxx] On Behalf Of James
Sutherland
Sent: Tuesday, February 10, 2009 5:33 AM
To: eclipselink-users@xxxxxxxxxxx
Subject: RE: [eclipselink-users] SQL emitted by EclipseLink is
searchingforan object with a null primary key


>From the stack the query is being executed by the cascaded locking
policy, I
assume you are using cascaded locking on the new Visit which is
privately
owned by the new Service?  Did you set the ManyToOne back reference, as
it
seems to be null?

It seems odd that it would be trying to query for the parent, especially
for
a new object, so might be good to log a bug for this, as the code does
not
seem correct.  Include this post in the bug.

>>>
RE: SQL emitted by EclipseLink is searching foran object with a null
primary
key Click to flag this post

by Gschwind, Doug Feb 09, 2009; 01:20pm :: Rate this Message: (use
ratings
to moderate[?])

Reply | Reply to Author | Delete | Show Only this Message
Hi James,

Sure, let me give you a little more context. The relevant domain model
classes for this use case are : Chart, Visit, and Service (and
subclasses of Service). There is a OneToMany from Chart to Visit, a
ManyToOne from Visit to Chart, a OneToMany from Visit to Service, and a
ManyToOne from Service to Visit, that are all JPA mapped.

In this use case, we are simply trying to create a new Service instance
and make it persistent, stitching up all of the appropriate
relationships prior to attempting to persist. Also, the Chart instance
is already persistent. I believe we are also going to persist a Visit as
part of creating a new Service in my test case.

Attached you will find the standard output stream from OC4J, with the
EclipseLink logging level set to FINEST. Additionally, I used the
StackDumpingPerformanceProfiler (a specialization of EclipseLink's
PerformanceProfiler provided to us by Randy Stafford) to help see the
stack trace that caused the query to be executed.

On line 7390 in the output you will see the odd select statement of the
form, SELECT * from SERVICE where SVCID = null. If you then look on line
7399, you can trace the cause of that SQL statement to where in our code
we call EntityManager.flush().

Let me know if I can provide you some more info.

Thanks,

Doug

-----
---
http://wiki.eclipse.org/User:James.sutherland.oracle.com James
Sutherland 
http://www.eclipse.org/eclipselink/
 EclipseLink ,  http://www.oracle.com/technology/products/ias/toplink/
TopLink 
Wiki:  http://wiki.eclipse.org/EclipseLink EclipseLink , 
http://wiki.oracle.com/page/TopLink TopLink 
Forums:  http://forums.oracle.com/forums/forum.jspa?forumID=48 TopLink ,

http://www.nabble.com/EclipseLink-f26430.html EclipseLink 
Book:  http://en.wikibooks.org/wiki/Java_Persistence Java Persistence 
-- 
View this message in context:
http://www.nabble.com/SQL-emitted-by-EclipseLink-is-searching-for-an-obj
ect-with-a-null-primary-key-tp21881456p21933675.html
Sent from the EclipseLink - Users mailing list archive at Nabble.com.

_______________________________________________
eclipselink-users mailing list
eclipselink-users@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipselink-users






The contents of this electronic mail message and any attachments are confidential, possibly privileged and intended
for the addressee(s) only. Only the addressee(s) may read, disseminate, retain or otherwise use this message. If
received in error, please immediately inform the sender and then delete this message without disclosing its contents
to anyone.