[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: Re[eclipselink-users] use of JPA mapped object copy
|
A.C.A == A should always be true, so this is very odd. Something strange is
occurring, are you sure you are using EclipseLink? Try setting logging to
finest and see what is occurring.
One possibility is that your primary key or relationship is not setup
correctly.
Perhaps try the same test with another model or one of the EclipseLink
examples to confirm that this is true.
Are you calling clear(), or using JTA and ending the transaction?
Gschwind, Doug wrote:
>
> Hello everyone,
>
>
>
> I am using EclipseLink 1.0.1 and have the default implicit copy on read
> behavior enabled in my JDK 1.5 environment. What I have recently
> discovered was that copies of objects made previously are not being
> reused in certain situations, and I would like to create as few copies
> of my mapped objects as possible to reduce heap needed to hydrate and
> interrogate a given domain object graph.
>
>
>
> Suppose I have the following simplified domain model with a one to many
> from C to A and a back pointing many to one from A to C :
>
>
>
> public class C
>
> {
>
> @Id
>
> private int id;
>
>
>
> @OneToMany(fetch=LAZY, mappedBy="c", cascade={ALL})
>
> private List as;
>
> ...
>
> }
>
>
>
> public class A
>
> {
>
> @ManyToOne(fetch=LAZY)
>
> @JoinColumn(name="C_FK")
>
> private C c;
>
>
>
> public C getC() { return c; }
>
> ...
>
> }
>
>
>
> Further, suppose I find a given instance of C with a simple primary key
> based JQPL query as depicted in the following code snippet :
>
>
>
> EntityManager em = getEntityManager();
>
> Query q = em.createQuery("SELECT c FROM C c WHERE c.id = :id");
>
> q.setParameter("id", idOfInterest);
>
> C result = (C) q.getSingleResult();
>
> em.close();
>
>
>
> 1. After the call to em.close(), if I interrogate the A instances of the
> resulting C instance returned, I see that the C instance returned by
> each A instance's getC() method is not the same as the original C
> instance returned. i.e. someA.getC() == originalC is false. This I
> expect since the C instance becomes detached at the moment the
> EntityManager is closed.
>
>
>
> 2. However, if I instead interrogate the C's A instances and perform the
> same interrogation prior to the em.close() call, I see the same results,
> which I am not expecting. I would expect that calling getC() on an
> instance of A would return the C result instance since the EntityManager
> is still open at that point in time and thus the C result instance is
> not yet detached.
>
>
>
> 3. Further, I find that if I mark both relationships as being EAGER,
> then all of the A instance's getC() calls do in fact return the same C
> result reference. This happens when the interrogation happens prior to
> the em.close() call, and I would expect the same result after the C
> instance is detached since the relationships are fully hydrated.
>
>
>
> Are all three of these test results to be expected?
>
>
>
> I now need to further refine my question. In my domain model, there is
> also a OneToMany from A to B, and a back pointing ManyToOne from B to A.
> In terms of a typical object graph, a given C instance may have 30 A
> instances and of all of those A instances, could have hundreds or
> thousands of B instances in total. In my test object graph, the C
> instance has some 80 or so A instances and some 3000 or so B instances.
>
>
>
> I could instead use Fetch Joins to express the desire to eagerly load
> the A and B instances, and leave those annotations specifying lazy
> loading, which of course would give me better control for eagerly
> loading those relationships on a use case by use case basis. However,
> that approach concerns me due to the "performance implications" noted at
> the top of page 206 of Mike Keith's and Merrick Schincariol's Pro EJB 3
> book. Additionally, I have found that this technique also results in the
> back pointing C reference to be a different C reference than that
> originally read.
>
>
>
> If I change the JPQL to instead look like :
>
>
>
> SELECT c FROM C c JOIN c.as a JOIN FETCH c.as JOIN FETCH a.c JOIN FETCH
> a.bs WHERE c.id = :id
>
>
>
> I do not see the same results as I saw in point 3 above, but the query
> does run fine otherwise. The same is true if I eliminate the JOIN FETCH
> a.c part of the above query as well. I should note that I have attempted
> this with batch reading being used for the A's B instances as well.
>
>
>
> Have I exhausted the techniques currently available to avoid the
> creation of "extra" domain object copies?
>
>
>
> Thank you,
>
>
>
> Doug Gschwind
>
>
>
>
>
>
>
> 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.
>
-----
---
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/Reuse-of-JPA-mapped-object-copy-tp20949274p21060822.html
Sent from the EclipseLink - Users mailing list archive at Nabble.com.
