Another StackOverflowError

Question

Hi all,
I have a cyclic graph stored in database where each graph-node is the following class
@Entity
public class Crossing {
@Id
private Long id;
@OneToMany
private Collection<Crossing> neighbours;
Each Crossing has a OneToMany relation to other Crossings as its neighbours.
Then I have a wrapping object PathCrossing defined:
@Entity
public class PathCrossing {
@Id
@GeneratedValue
private Long id;
private Integer crossingOrder;
@OneToOne
private Crossing crossing;
To explain it completely, I have also class Path, which has OneToMany relation with PathCrossing. Thus Path contains several PathCrossings, which r
elates OneToOne to Crossings. PathCrossing exists just because of storing the index of the Crossing to keep them ordered.
Now, the Crossings are already persisted. I load them and without any modification I assign them to newly created PathCrossings, which I persist then. The StackOverflowError appears when I commit the transaction. The stack trace looks like:
Exception in thread "main" java.lang.StackOverflowError
at oracle.toplink.essentials.internal.sessions.AbstractSession.isClassReadOnly(AbstractSession.java:1840)
at oracle.toplink.essentials.internal.ejb.cmp3.base.RepeatableWriteUnitOfWork$1.iterate(RepeatableWriteUnitOfWork.java:114)
at oracle.toplink.essentials.internal.descriptors.DescriptorIterator.internalIterateReferenceObject(DescriptorIterator.java:174)
at oracle.toplink.essentials.internal.descriptors.DescriptorIterator.iterateReferenceObjectForMapping(DescriptorIterator.java:281)
at oracle.toplink.essentials.mappings.CollectionMapping.iterateOnElement(CollectionMapping.java:621)
at oracle.toplink.essentials.mappings.CollectionMapping.iterateOnRealAttributeValue(CollectionMapping.java:635)
at oracle.toplink.essentials.internal.descriptors.DescriptorIterator.iterateIndirectContainerForMapping(DescriptorIterator.java:232)
at oracle.toplink.essentials.internal.indirection.TransparentIndirectionPolicy.iterateOnAttributeValue(TransparentIndirectionPolicy.java:287)
at oracle.toplink.essentials.mappings.ForeignReferenceMapping.iterate(ForeignReferenceMapping.java:571)
at oracle.toplink.essentials.internal.descriptors.ObjectBuilder.iterate(ObjectBuilder.java:2061)
at oracle.toplink.essentials.internal.descriptors.DescriptorIterator.iterateReferenceObjects(DescriptorIterator.java:296)
at oracle.toplink.essentials.internal.descriptors.DescriptorIterator.iterateReferenceObjectForMapping(DescriptorIterator.java:287)
at oracle.toplink.essentials.mappings.CollectionMapping.iterateOnElement(CollectionMapping.java:621)
at oracle.toplink.essentials.mappings.CollectionMapping.iterateOnRealAttributeValue(CollectionMapping.java:635)
at oracle.toplink.essentials.internal.descriptors.DescriptorIterator.iterateIndirectContainerForMapping(DescriptorIterator.java:232)
at oracle.toplink.essentials.internal.indirection.TransparentIndirectionPolicy.iterateOnAttributeValue(TransparentIndirectionPolicy.java:287)
I find it weird that even though I didn't make any modification to Crossing (and there is also no cascade defined on the relation), Toplink traverses through them. Is there any way how to tell Toplink not to do that, since the Crossings are not modified? I understand that if it starts recursively traversing them, it ends up with StackOverflow, because there is simply too much of them. The amount of the Crossings is approx. 22000 and they are quite heavily connected (each Crossing has in avg. 3-4 neighbours).
Generaly, I'm wondering how to handle persistence of such large graphs. I had a similar problem before when I was persisting the graph, and I finally managed using native SQL queries. I'd like to avoid them for this time.
I'm using toplink-essentials-2.0-36 (02/17/2007) and I also tried 2.0-b41-beta2 (03/30/2007) (which is most recent I think) and I got the same results.
Thanks a lot for any advice!
Petr

Answer 1

Hi,
did you get any reply through other channels. I have a very similar issue with cross-linked information. I have 14k cross-linked objects (29k links) and want to update a plain field in these objects. The entire computation runs to completion and the method returns to the caller (almost). I get the error on the application client which then rolls-back an almost completed update.
Thanks,
Marius