I've gotten around this error by reconfiguring a few of my bidirectional
relations (the cascade options), adding more explicit calls to
EntityManager.persist instead of relying on cascade behavior, and
aggressively detaching newly persisted objects during batch loading via
EntityManager.clear.
Andy
Andy Schlaikjer wrote:
Hi,
I'm running Linux, Sun JDK 1.6.0_01-b06, and OpenJPA 1.0.1. When
attempting to persist a relatively large object graph (though size in
data isn't horribly large) via cascade, I'm running into this exception:
Exception in thread "main" java.lang.StackOverflowError
at java.security.AccessController.doPrivileged(Native Method)
at
org.apache.openjpa.enhance.Reflection.getDeclaredField(Reflection.java:166)
at
org.apache.openjpa.enhance.Reflection.findField(Reflection.java:145)
at
org.apache.openjpa.enhance.edu$cmu$albatross$dblp$Field$pcsubclass.pcProvideField(Unknown
Source)
at
org.apache.openjpa.kernel.StateManagerImpl.provideField(StateManagerImpl.java:2959)
at
org.apache.openjpa.kernel.StateManagerImpl.fetchObjectField(StateManagerImpl.java:2201)
at
org.apache.openjpa.kernel.StateManagerImpl.fetchField(StateManagerImpl.java:759)
at
org.apache.openjpa.kernel.StateManagerImpl.fetch(StateManagerImpl.java:721)
at
org.apache.openjpa.kernel.StateManagerImpl.dirtyCheck(StateManagerImpl.java:807)
at
org.apache.openjpa.kernel.BrokerImpl$ManagedCache.dirtyCheck(BrokerImpl.java:4620)
at
org.apache.openjpa.kernel.BrokerImpl$ManagedCache.access$000(BrokerImpl.java:4360)
at
org.apache.openjpa.kernel.BrokerImpl.hasTransactionalObjects(BrokerImpl.java:3739)
at
org.apache.openjpa.kernel.BrokerImpl.setDirty(BrokerImpl.java:3856)
at
org.apache.openjpa.kernel.StateManagerImpl.setPCState(StateManagerImpl.java:207)
at
org.apache.openjpa.kernel.StateManagerImpl.dirty(StateManagerImpl.java:1532)
at
org.apache.openjpa.kernel.StateManagerImpl.dirty(StateManagerImpl.java:1471)
at
org.apache.openjpa.kernel.StateManagerImpl.dirtyCheck(StateManagerImpl.java:808)
at
org.apache.openjpa.kernel.BrokerImpl$ManagedCache.dirtyCheck(BrokerImpl.java:4620)
at
org.apache.openjpa.kernel.BrokerImpl$ManagedCache.access$000(BrokerImpl.java:4360)
at
org.apache.openjpa.kernel.BrokerImpl.hasTransactionalObjects(BrokerImpl.java:3739)
...
Afterwards, the trace repeats these lines over and over:
at
org.apache.openjpa.kernel.BrokerImpl.setDirty(BrokerImpl.java:3856)
at
org.apache.openjpa.kernel.StateManagerImpl.setPCState(StateManagerImpl.java:207)
at
org.apache.openjpa.kernel.StateManagerImpl.dirty(StateManagerImpl.java:1532)
at
org.apache.openjpa.kernel.StateManagerImpl.dirty(StateManagerImpl.java:1471)
at
org.apache.openjpa.kernel.StateManagerImpl.dirtyCheck(StateManagerImpl.java:808)
at
org.apache.openjpa.kernel.BrokerImpl$ManagedCache.dirtyCheck(BrokerImpl.java:4620)
at
org.apache.openjpa.kernel.BrokerImpl$ManagedCache.access$000(BrokerImpl.java:4360)
at
org.apache.openjpa.kernel.BrokerImpl.hasTransactionalObjects(BrokerImpl.java:3739)
at
org.apache.openjpa.kernel.BrokerImpl.setDirty(BrokerImpl.java:3856)
Could anyone help explain what the cause might be, or how I might avoid
this type of error? I guess I'd need to somehow determine a reasonable
bound on number of objects to attempt to persist in a single transaction
and then divvy up my object graph to accommodate this.
Thanks,
Andy
