Duplicate :
|
|
Duplicate :
|
|
Duplicate :
|
|
Duplicate :
|
Summary: Serializing recursively calls writeObject, resulting in java.lang.StackOverFlowError being thrown when the object graph is deeply nested (example: long link list). Since serialiation is being performed on a server that spawns a thread for each client, it is not possible to up the stack size to workaround this capacity limitation for each thread. Customer mail message: Apparently an object O is serialized in a "pre-order" walk of the object graph rooted at O. Thus if O points to O', O' is serialized first, and then O. JDK 1.1.6 and earlier versions seem to implement this by using the stack to do the recursion. This has the hugely unfortunate property of limiting the size of the graphs that can be serialized. Trying to serialize a linked list of 1000 elements blew my stack on an WinNT! In essence, one cannot serialize an object graph which can grow arbitrarily large. I am led to believe that it is not possible in Java to grow the stack size arbitrarily in a data-dependent manner from inside the JVM. Why not do this recursion in the heap then? Or, perhaps even better, why not do the serialization in a "post-order" walk (generating a handle on O', stashing that away in a table, finishing the serialization of O (using the handle for all future accesses to O') and then coming back to serialize all the objects in the table that have not yet been serialized)? Are any patches available for this functionality? I can try to fake it in my application, but the problem is that I do not control the code being loaded into the JVM --- so I cannot control the {write/read}Object methods for all classes.
|