I think you might be bumping into how Castor retrieves parent-child related objects. AFAIK, Castor uses outer joins to put all the necessary data into a single result set. Other people have reported similar issues when reading back large numbers of related objects.
Ultimately, I think the fix is to refactor how Castor loads related objects so that multiple queries are used instead of one large outer joined query. I don't believe there are any plans to do this soon, though. --Kevin -----Original Message----- From: Gomes, Kevin [mailto:[EMAIL PROTECTED]] Sent: Tuesday, May 14, 2002 1:24 PM To: [EMAIL PROTECTED] Subject: [castor-dev] Limitations to the number of objects (chained) that can be retrie ved from DB? Hello All, Has anyone ever had any kind of limitation on the number of objects that can be retrieved from a database? I basically have a chained (it is a Vector) set of objects that represent a parent-child relationship. I build the chain of objects and call db.create on the "root" object. Castor has no problem with this and creates all the data in the DB just fine. I have created chains as long as 1000 objects and it writes it to the database flawlessly. When I try to read the root object back however, any chain that was created longer than 758 objects will throw a StackOverFlowError. I have tried adjusting the memory size for the JVM but nothing changes. I have tried all the different caching methods and nothing changes. I have tried different machines and nothing changes. It seems to be the length of the chain that is the problem (BTW, I am using Microsoft SQL Server). Here is the mapping file that I am using: ---------------------------------------------------------------------------- -- <!DOCTYPE databases PUBLIC "-//EXOLAB/Castor Mapping DTD Version 1.0//EN" "http://castor.exolab.org/mapping.dtd";> <mapping> <!-- Mapping for ConceptImpl --> <class name="org.mbari.dsg.Concept" identity="conceptID" key-generator="IDENTITY"> <description>Concept</description> <map-to table="Concept" /> <cache-type type="none"/> <!-- Map the conceptID field --> <field name="conceptID" type="integer"> <sql name="ConceptID" type="integer"/> </field> <!-- Map the PrimaryName field --> <field name="conceptName" type="org.mbari.dsg.ConceptName"> <sql name="PrimaryName"/> </field> <!-- Map the parent field --> <field name="parent" type="org.mbari.dsg.Concept" required="true"> <sql name="parent_conceptID" many-table="child_parent" many-key="child_conceptID" /> </field> <!-- Map the child concepts field --> <field name="childConceptSet" type="org.mbari.dsg.Concept" required="true" collection="vector"> <sql name="child_conceptID" many-table="child_parent" many-key="parent_conceptID"/> </field> <!-- Map the conceptNameSet field --> <field name="conceptNameSet" type="org.mbari.dsg.ConceptName" required="true" collection="vector" set-method="setConceptNameSet" get-method="getConceptNameSet"> <sql many-key="ConceptName_ConceptID"/> </field> </class> <!-- Mapping for ConceptName class --> <class name="org.mbari.dsg.ConceptName" identity="name" depends="org.mbari.dsg.Concept" > <map-to table="ConceptName" /> <cache-type type="none"/> <field name="name" type="string"> <sql name="ConceptName" type="char" /> </field> <field name="author" type="string"> <sql name="Author" type="char" /> </field> <field name="type" type="string"> <sql name="NameType" type="char" /> </field> <field name="concept" type="org.mbari.dsg.Concept"> <sql name="ConceptName_ConceptID" /> </field> </class> </mapping> ---------------------------------------------------------------------------- --- The Concept class is the one with the parent-child relationship and the ConceptName class is just a related class (Concept has one or more ConceptNames, but this does not appear to affect anything). The parent-child chain of class 'Concept' is the one that I am testing (Just think of the ConceptName class as the name of the Concept class). The code snippet looks like this: ---------------------------------------------------------------------------- --- org.exolab.castor.jdo.OQLQuery newQuery = jdoDB.getOQLQuery("SELECT c FROM org.mbari.dsg.Concept c WHERE c.conceptName.name = $1"); newQuery.bind(rootNames[i]); org.exolab.castor.jdo.QueryResults results = newQuery.execute(); if(results.hasMore()) { conceptToRead = (Concept)results.next(); } ---------------------------------------------------------------------------- --- Again, this works fine until I create a chain of objects longer than 758. Then I get the following error: java.lang.reflect.InvocationTargetException: java.lang.StackOverflowError at org.mbari.dsg.ConceptName.setAuthor(ConceptName.java:93) at java.lang.reflect.Method.invoke(Native Method) at org.exolab.castor.persist.FieldMolder.setValue(FieldMolder.java:313) at org.exolab.castor.persist.ClassMolder.load(ClassMolder.java:705) at org.exolab.castor.persist.LockEngine.load(LockEngine.java:359) at org.exolab.castor.persist.TransactionContext.load(TransactionContext.java:57 5) at org.exolab.castor.persist.TransactionContext.load(TransactionContext.java:48 6) at org.exolab.castor.persist.ClassMolder.load(ClassMolder.java:749) at org.exolab.castor.persist.LockEngine.load(LockEngine.java:359) at org.exolab.castor.persist.TransactionContext.load(TransactionContext.java:57 5) at org.exolab.castor.persist.TransactionContext.load(TransactionContext.java:48 6) at org.exolab.castor.persist.ClassMolder.load(ClassMolder.java:775) at org.exolab.castor.persist.LockEngine.load(LockEngine.java:359) at org.exolab.castor.persist.TransactionContext.load(TransactionContext.java:57 5) at org.exolab.castor.persist.TransactionContext.load(TransactionContext.java:48 6) ----------------------------------------------------------- If you wish to unsubscribe from this mailing, send mail to [EMAIL PROTECTED] with a subject of: unsubscribe castor-dev
