[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [eclipselink-users] Lazy loading scenario
|
I've managed to duplicate this exact thing in a simple example project.
I zipped it up, including all dependencies (uses postgres, but I'm sure
another db can be swapped in). The Eclipse project is set up to run with
JPA2.x and the error can be seen. The jars (and persistence.xml) are
also there to run under jpa1.x and it can be seen that it passes. This
well describes the bug I now see after my upgrade.
I tried a find() in there instead of a merge() as James suggested, but
made no difference. I'll try individual entity merge()s next, but that
seems very brittle.
The project can be downloaded from:
http://kvisit.com/SpbKmAQ (10MB)
(please let me know if any problems accessing it)
I appreciate any and all help!
Brad
On 2/04/11 7:48 AM, Brad Milne wrote:
Thanks James
Just working on a simple example project to try to duplicate more simply.
Cheers
Brad
On 25/03/11 6:28 AM, James Sutherland wrote:
Odd, can't see why an existing object would be inserted form a
merge(). What
is the related object and how is it mapped?
Why are you calling merge(), and you updating the object? Are you
creating
new objects as well, or associating new objects with the existing
object?
This may be related to bug,
https://bugs.eclipse.org/bugs/show_bug.cgi?id=340802
Try using find() to find the object first, or merging each object one
by one
not using cascade on the merge.
Brad Milne wrote:
Hi all
I have a user screen (thick client; Swing) that presents a list of
sound recording entities, including metadata such as date and
time.
These range up to 211kb in size (average 30kb) and can be up to 3k
of them presented at a time. I can't fully load them in one go as
get OOM errors. To solve this, I use lazy loading (@Basic(fetch =
FetchType.LAZY)) on the sound data attribute of the entity. I've
recently upgraded to eclipselink 2.1.2 from 1.0.2 and am having
some
strange behaviour.
What happens in the code is this:
Load:
Get all records (sound data is lazy loaded so memory minimal)
entityManager.clear() to detach all records from the db
User selects a record:
entityManager.merge() the selected recording, inserting it in
place of the detached object in the list
User listens to the recording which fetches the sound data
User selects a different recording:
entityManager.clear() to detach all records from the db - yes,
again. If I didn't do this then all recordings are loaded by the
time the screen has been completed and the same memory issues are
present.
entityManager.merge() the selected recording, inserting it in
place of the detached object in the list
User listens to the recording which fetches the sound data
and so on...
This worked fine in 1.0.2. It felt clunky, but seemed to be OK.
In 2.1.2 it is not working. Looking into it, it seems to be trying
to insert a new instance of a related singleton reference object,
for which a duplicate ID exception is generated. My interpretation
is that the clear() is detaching all entities, then a new
one is being created for the update (commit). This seems perfectly
reasonable, but it breaks my current implementation, and didn't
happen in 1.0.2.
So 1) Is there a way to detach individual entities (or their
fields)
after they have been accessed/modified/then committed?
2) Does somebody know what changed that affected this? Was it a
regression that's since been fixed, maybe?
2) Or should I be completely rethinking the pattern I'm using
here?
Thanks a lot in advance
Brad
-----
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
Blog: http://java-persistence-performance.blogspot.com/ Java
Persistence
Performance