Problem of cycle and stackoverflow when using JPA @OneToMany mapping Tag

Question

Hello everyone!
Description:
We are using the tag @OneToMany to map a collection of objects in an entity. In the other side, we use the tag @ManyToOne to map the father.
Our simple example for testing consist of the following entities:
This is the class Child:
@Entity
@Table(name="TEST_CHILD")
public class Child implements Serializable{
@Id
@Column(name="ID_CHILD")
private Long id;
@ManyToOne(fetch=FetchType.LAZY)
@JoinColumn(name="ID_FATHER", referencedColumnName="ID_FATHER")
private Father father;
and this is the Father class:
@Entity
@Table(name="TEST_FATHER")
public class Father implements Serializable{
@Id
@Column(name="ID_FATHER")
private Long id;
@OneToMany(mappedBy="father", fetch=FetchType.EAGER)
private List<Child> children;
Problem:
When a select over this entities is realized, we are getting the folling exception:
The following Error is thrown by the VM [java.lang.StackOverflowError]. ErrorQueueHandler will just trace it. The caller component should take care to process it properly.
java.lang.StackOverflowError
at java.lang.Class.searchMethods(Class.java:2646)
We've already used @OneToMany and @ManyToOne mapping in many other projects, and we've tried different parameters on the tags as well, but we still getting the exception. If applying fetch mode Lazy to the @OneToMany we had an detatched exception, cause ou the context. Anyways, we need and would like to use the EAGER loading mode.
So what seems to happen is that the application runs into a cycle when loading the "father" attribute of Child, recreating the list collection within it.
This same configuration works just fine in other implementations (i.e.: Hibernate JPA implementation), and many other examples over the web are not different of our implementation.
Any suggestion of how we could solve this problem? Is this a standart behavior of mapping using Sap JPA?
Evandro Pomatti
Edited by: Evandro Pomatti on Dec 9, 2010 9:55 PM

Answer 1

hi evandro,
now I got same kind of error, how did you fix, pls help if you have remembered,
hi all,
I am getting folowing error in my JAVA portal system when executing webservices in WSnavigator.
if anyone would have been faced this kind of error pls help me.
The following Error is thrown by the VM [java.lang.StackOverflowError]. ErrorQueueHandler will just trace it. The caller component should take care to process i
t properly.
completere error log
#2.#2014 04 27 23:52:42:197#0-500#Warning#com.sap.engine.core.thread.impl3.ErrorQueueHandler#
com.sap.ASJ.krn_thd.000025#BC-JAS-COR#kernel.sda#C0000AF060EF002D000001A901AA0076###com.sap.engine.core.thread.impl3.ErrorQueueHandler#Guest#0##9586B2DBCCBD11E3
A75E0000033325C2#9586b2dbccbd11e3a75e0000033325c2#9586b2dbccbd11e3a75e0000033325c2#0#Thread[ErrorQueueWatchDog,5,main]#Plain##
The following Error is thrown by the VM [java.lang.StackOverflowError]. ErrorQueueHandler will just trace it. The caller component should take care to process i
t properly.
java.lang.StackOverflowError
        at java.security.AccessController.doPrivileged(Native Method)
        at java.io.FilePermission.init(FilePermission.java:183)
        at java.io.FilePermission.<init>(FilePermission.java:249)
        at sun.net.www.protocol.file.FileURLConnection.getPermission(FileURLConnection.java:198)
        at sun.security.provider.PolicyFile.canonicalizeCodebase(PolicyFile.java:1784)
        at sun.security.provider.PolicyFile.access$700(PolicyFile.java:264)
        at sun.security.provider.PolicyFile$7.run(PolicyFile.java:1247)
        at java.security.AccessController.doPrivileged(Native Method)
        at sun.security.provider.PolicyFile.getPermissions(PolicyFile.java:1243)
        at sun.security.provider.PolicyFile.getPermissions(PolicyFile.java:1190)
        at com.sap.engine.services.security.jacc.provider.PolicyImpl.implies(PolicyImpl.java:71)
        at com.sap.security.core.UmePolicy.implies(UmePolicy.java:696)
        at com.sap.security.core.role.jacc.JACCPolicy.implies(JACCPolicy.java:367)
        at java.security.ProtectionDomain.implies(ProtectionDomain.java:222)
        at java.security.AccessControlContext.checkPermission(AccessControlContext.java:354)
        at java.security.AccessController.checkPermission(AccessController.java:549)
        at com.sap.engine.services.keystore.impl.security.CodeBasedSecurityConnector.checkPermissions_readEntry(CodeBasedSecurityConnector.java:542)
and also find heap log info
-----------  H E A P   C H E C K  -----------
Suspension of other threads succeeded.
6 Java thread local allocation buffers currently in use.
Scanning young generation space 314368K,   1% used [0x0a00020000000000, 0x0a00020000334838, 0x0a00020013300000)
Scanning young generation space 157184K,   0% used [0x0a00020013300000, 0x0a00020013300000, 0x0a0002001cc80000)
Scanning young generation space 157184K,   0% used [0x0a0002001cc80000, 0x0a0002001cc80000, 0x0a00020026600000)
Scanning old generation space 2516992K,  21% used [0x0a00020026600000, 0x0a000200c0000000)
Scanning permanent generation space 409600K,  99% used [0x0a000200c0000000, 0x0a000200d9000000)
Checked the complete java heap.
---  N O   H E A P   C O R R U P T I O N  ---
-----------  R E G I S T E R   R E G I O N S  -----------
Register pc points to 0x09000000332ef3a8, which is not a known memory location
Register lr points to 0x09000000332ef388, which is not a known memory location
Register ctr points to 0x0900000033421bc0, which is not a known memory location
Register r0 points to 0x0000000000000000, which is not a known memory location
Register r1 points into the stack of JavaThread "HTTP Worker [@1753615133]" [_thread_in_vm (_call_back), id=25193, stack(0x000000011a5ef888,0x000000011a6ef888)]
Dump of memory region around register r1 at 0x000000011a6e2a70
   0x000000011a6e29f0 00 00 00 01 1A 6E 2A 70 00 00 00 00 00 00 00 15 [.....n*p........]
   0x000000011a6e2a00 09 00 00 00 33 63 12 DC 09 00 10 00 A6 6A F9 60 [....3c.......j.`]
   0x000000011a6e2a10 00 00 00 00 12 4C 35 C0 0A 00 01 00 16 3D 60 78 [.....L5......=`x]
   0x000000011a6e2a20 09 00 00 00 33 FB 54 98 00 00 00 00 33 F4 90 28 [....3.T.....3..(]
   0x000000011a6e2a30 09 00 10 00 A6 4D 98 10 00 00 00 01 1A 6E 2A E8 [.....M.......n*.]
   0x000000011a6e2a40 00 00 00 00 00 00 00 00 00 00 00 00 15 A8 00 69 [...............i]
   0x000000011a6e2a50 00 00 00 00 15 A8 00 69 09 00 00 00 33 F4 90 38 [.......i....3..8]
   0x000000011a6e2a60 00 00 00 00 00 00 01 08 00 00 00 00 00 00 00 00 [................]
=> 0x000000011a6e2a70 00 00 00 01 1A 6E 2B 60 00 00 00 00 00 00 00 08 [.....n+`........]
Register r2 points to 0x09001000a66af960, which is not a known memory location
Register r3 points to 0x00000001188fa130, which is not a known memory location
Register r4 points to 0x0a000100163d6098, which is not a known memory location
Register r5 points to 0x0900000033f49038, which is not a known memory location
Register r6 points to 0x0000000000000108, which is not a known memory location
Register r7 points to 0x09001000a648c308, which is not a known memory location
Register r8 points to 0x09001000a64cf2b4, which is not a known memory location
Register r9 points to 0x0000000000000000, which is not a known memory location
Register r10 points to 0x0000000000000000, which is not a known memory location
Register r11 points to 0x0000000000000000, which is not a known memory location
Register r12 points to 0x09000000332ef388, which is not a known memory location
Register r13 points into the stack of JavaThread "HTTP Worker [@2116488621]" [_thread_in_native (_at_safepoint), id=25450, stack(0x000000011a6f4888,0x000000011a
7f4888)]
[error occurred during error reporting (dumping memory regions for register values), id 0xb
Exception details: SIGSEGV at pc=0
Problematic frame: v  ~StubRoutines::SafeFetch32 (sp=0x000000011a6e1240) (pc=0x0a00010000067b58)]
hs_err_pid26214604.log: END