Skip to main content

Fetch.Lazy and ManyToMany

3 replies [Last post]
miklernout
Offline
Joined: 2003-06-13

All,

I am having some issues with a ManyToMany relationship marked as being Lazy. When I execute a query for this entity (as in "select t from Thing t" ) the object building code of Toplink is calling the getter of the field and hitting the Lazy relationship, kind of defeating the purpose of having it marked as Lazy in the first place.

I put a stacktrace dump in the getter, to get an idea of the Toplink code that is hitting the getter. Does anybody know a workaround to this problem and should I post this as an issue?

Mik

java.lang.Exception
at com.maketechnologies.tlm.semanticator.objectmodel.Thing.getLabels(Thing.java:156)
at sun.reflect.GeneratedMethodAccessor71.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at oracle.toplink.essentials.internal.security.PrivilegedAccessHelper.invokeMethod(PrivilegedAccessHelper.java:307)
at oracle.toplink.essentials.internal.descriptors.MethodAttributeAccessor.getAttributeValueFromObject(MethodAttributeAccessor.java:76)
at oracle.toplink.essentials.mappings.DatabaseMapping.getAttributeValueFromObject(DatabaseMapping.java:357)
at oracle.toplink.essentials.mappings.ForeignReferenceMapping.getAttributeValueFromObject(ForeignReferenceMapping.java:317)
at oracle.toplink.essentials.mappings.ForeignReferenceMapping.buildBackupClone(ForeignReferenceMapping.java:99)
at oracle.toplink.essentials.internal.descriptors.ObjectBuilder.buildBackupClone(ObjectBuilder.java:302)
at oracle.toplink.essentials.descriptors.changetracking.DeferredChangeDetectionPolicy.buildBackupClone(DeferredChangeDetectionPolicy.java:163)
at oracle.toplink.essentials.internal.sessions.UnitOfWorkImpl.populateAndRegisterObject(UnitOfWorkImpl.java:2837)
at oracle.toplink.essentials.internal.sessions.UnitOfWorkImpl.cloneAndRegisterObject(UnitOfWorkImpl.java:673)
at oracle.toplink.essentials.internal.sessions.UnitOfWorkIdentityMapAccessor.getAndCloneCacheKeyFromParent(UnitOfWorkIdentityMapAccessor.java:152)
at oracle.toplink.essentials.internal.sessions.UnitOfWorkIdentityMapAccessor.getFromIdentityMap(UnitOfWorkIdentityMapAccessor.java:90)
at oracle.toplink.essentials.internal.sessions.IdentityMapAccessor.getFromIdentityMap(IdentityMapAccessor.java:295)
at oracle.toplink.essentials.internal.sessions.UnitOfWorkImpl.registerExistingObject(UnitOfWorkImpl.java:3075)
at oracle.toplink.essentials.internal.sessions.UnitOfWorkImpl.registerExistingObject(UnitOfWorkImpl.java:3024)
at oracle.toplink.essentials.queryframework.ObjectBuildingQuery.registerIndividualResult(ObjectBuildingQuery.java:319)
at oracle.toplink.essentials.internal.descriptors.ObjectBuilder.buildWorkingCopyCloneNormally(ObjectBuilder.java:441)
at oracle.toplink.essentials.internal.descriptors.ObjectBuilder.buildObjectInUnitOfWork(ObjectBuilder.java:406)
at oracle.toplink.essentials.internal.descriptors.ObjectBuilder.buildObject(ObjectBuilder.java:372)
at oracle.toplink.essentials.queryframework.ReportQueryResult.processItem(ReportQueryResult.java:205)
at oracle.toplink.essentials.queryframework.ReportQueryResult.buildResult(ReportQueryResult.java:167)
at oracle.toplink.essentials.queryframework.ReportQueryResult.(ReportQueryResult.java:83)
at oracle.toplink.essentials.queryframework.ReportQuery.buildObject(ReportQuery.java:579)
at oracle.toplink.essentials.queryframework.ReportQuery.buildObjects(ReportQuery.java:628)
at oracle.toplink.essentials.queryframework.ReportQuery.executeDatabaseQuery(ReportQuery.java:776)
at oracle.toplink.essentials.queryframework.DatabaseQuery.execute(DatabaseQuery.java:609)
at oracle.toplink.essentials.queryframework.ObjectLevelReadQuery.execute(ObjectLevelReadQuery.java:677)
at oracle.toplink.essentials.queryframework.ObjectLevelReadQuery.executeInUnitOfWork(ObjectLevelReadQuery.java:731)
at oracle.toplink.essentials.internal.sessions.UnitOfWorkImpl.internalExecuteQuery(UnitOfWorkImpl.java:2219)
at oracle.toplink.essentials.internal.sessions.AbstractSession.executeQuery(AbstractSession.java:937)
at oracle.toplink.essentials.internal.sessions.AbstractSession.executeQuery(AbstractSession.java:909)
at oracle.toplink.essentials.internal.ejb.cmp3.base.EJBQueryImpl.executeReadQuery(EJBQueryImpl.java:346)
at oracle.toplink.essentials.internal.ejb.cmp3.base.EJBQueryImpl.getResultList(EJBQueryImpl.java:453)
at com.maketechnologies.tlm.semanticator.web.base.search.SearchBackingBean.fetch(SearchBackingBean.java:142)

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
tware
Offline
Joined: 2005-06-24

Apparently a bug has been entered. Further discussion about this can be found at:

https://glassfish.dev.java.net/issues/show_bug.cgi?id=3328

tware
Offline
Joined: 2005-06-24

How is Thing mapped?

What does Thing.getLabels() do?

If you turn on logging do you see SQL when getLabels is called? (to turn on logging, add the persistence unit property toplink.logging.level=FINER)

miklernout
Offline
Joined: 2003-06-13

Note that I am not trying to fix the Exception, I put that in myself to get a stack-trace of the code calling it.

Thing is an @Entity, Thing.getLabels() is a vanilla getter (except for the debugging code mentioned above) When I show SQL, it is initializing the List returned by the getter and running the appropriate queries, which is not what I wanted when I marked the relationship to be LAZY.

I hope that clarifies.

Message was edited by: miklernout