Determining when/why objects are registered with the EM / UOW [message #1098848] |
Sat, 31 August 2013 19:56  |
Eclipse User |
|
|
|
I am using EclipseLink 2.4.2 in a J2EE environment. We are debugging a problem whereby EclipseLink attemps to insert two objects which violate a database constraint because they have the same foreign key values.
To briefly summarize the issue, there are two tables "A" and "B" with a many-to-many relationship between them, which in EclipseLink we have modeled as a separate table "AB" and associated Java class. There is a database constraint preventing the same two "A" and "B" objects from being associated more than once.
Looking at the SQL being output by EclipseLink at the flush(), it is trying to insert three rows into AB, two of which conflict. We are only intending on creating two objects, but a third is apparently created somewhere during the operation. The operation is a very complex batch operation with hundreds of rows of data processed by thousands of lines of code.
Somewhere throughout all of that code, a third instance of "AB" is being created and registered with the EntityManager, becomes part of the UnitOfWork, and is saved on the flush operation. However I am having difficulty in determining where or why that happens.
What I was hoping to find was either some API that I could call on the EntityManager or UnitOfWork to ask it when or how an object was registered, or a break point that I could set in the EclipseLink source code (which I have downloaded and integrated into my project) which would allow me to identify when the object was registered, so I could look up the stack and see what code in our system triggered this.
I feel that there must be some way of asking the EntityManager for its current set of dirty objects and operations, but haven't been able to find it. Thanks very much for any tips or advice.
|
|
|
|
Re: Determining when/why objects are registered with the EM / UOW [message #1100857 is a reply to message #1099427] |
Tue, 03 September 2013 18:00  |
Eclipse User |
|
|
|
The UnitOfWork/RepeatableWriteUnitOfWork instance that the EM delegates to has a few methods that might help, such as printRegisteredObjects() which will print off objects at the SEVERE log level, and getCloneMapping() for all clones/registered objects. EclipseLink only finds objects that haven't been persisted/merged directly (or where the persist/merge hasn't cascaded) when it calls calculateChanges()/discoverUnregisteredNewObjects(), so you might want to put breakpoints in there if all else fails. If you are accidently creating copies though, the easiest way might be to instrument your entities set methods and toString methods, so that you can inspect what is in the AB collection and see more accurately when two ABs are added that might reference the same B (or A if watching from the B side).
|
|
|
Powered by
FUDForum. Page generated in 0.05874 seconds