If something is *not* deterministic, it will be (quite) hard for us to
look at (and hopefully identity whether there's a problem).
To answer parts of your question, since polymorphism has been
implemented we had one or two issues related to a few special cases we
failed to consider in the initial implementation, e.g. a new child class
that does not specify any additional fields, etc.
But all in all things have proved to be quite ... stable.
Werner
PS The error in itself is .. strange. I'd not really expect an exception
to be thrown there. Can you pretty please tro to produce a test that
fails non-deterministically, and we'll definitely be having a look.
Jim Manico wrote:
> Hello,
>
> I've been a fan and successful user of Castor for 6+ years now.
>
> I've just started working with the Polymorphism features recently - and
> at first they worked wonderfully, but recently I started seeing the
> following error when trying to load an object after writing to it a few
> times. I saw a lot of talk about this problem in 2005 - but then all
> went quiet on this issue. Has there been are any resolution as to why
> these kinds of bugs pop up since the days of bugs CASTOR-1195 getting
> solved?
>
> Also, I cannot seem to recreate this bug in a deterministic fashion.
>
> java.lang.ArrayIndexOutOfBoundsException: 7
> org.castor.persist.ProposedEntity.getField(ProposedEntity.java:103)
>
> org.castor.persist.resolver.ManyRelationResolver.load(ManyRelationResolver.java:254)
> org.exolab.castor.persist.ClassMolder.load(ClassMolder.java:638)
> org.exolab.castor.persist.LockEngine.load(LockEngine.java:396)
>
> org.castor.persist.AbstractTransactionContext.load(AbstractTransactionContext.java:568)
>
> org.castor.persist.AbstractTransactionContext.load(AbstractTransactionContext.java:431)
>
> org.castor.persist.resolver.ManyRelationResolver.load(ManyRelationResolver.java:272)
> org.exolab.castor.persist.ClassMolder.load(ClassMolder.java:638)
> org.exolab.castor.persist.LockEngine.load(LockEngine.java:396)
>
> org.castor.persist.AbstractTransactionContext.load(AbstractTransactionContext.java:568)
>
> org.castor.persist.AbstractTransactionContext.load(AbstractTransactionContext.java:431)
>
> org.exolab.castor.jdo.engine.AbstractDatabaseImpl.load(AbstractDatabaseImpl.java:301)
>
> org.exolab.castor.jdo.engine.AbstractDatabaseImpl.load(AbstractDatabaseImpl.java:272)
>
> com.codemagi.servlets.NavigationController.dispatchCommand(NavigationController.java:108)
>
> com.codemagi.servlets.NavigationController.service(NavigationController.java:56)
> javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
>
>
> And once I get this (polymorphism specific) bug on one object, the
> entire engine starts to break down, and I get errors like this at login.
>
> org.exolab.castor.jdo.TransactionAbortedException: Nested error:
> org.exolab.castor.jdo.LockNotGrantedException:
> persist.writeTimeoutcom.codemagi.login.model.User/<1(1)>/232 by
> [EMAIL PROTECTED]:
> persist.writeTimeoutcom.mycode.login.model.User/<1(1)>/232 by
> [EMAIL PROTECTED]
>
> My polymorphic mapping is relatively simple (MySQL).
>
> *I have a core Node:*
>
> <!-- Key generator for Node -->
> <key-generator name="IDENTITY" alias="NODE_SEQ"/>
>
> <!-- Mapping for Node -->
> <class name="com.mycode.servlets.model.Node" identity="id"
> key-generator="NODE_SEQ" cache-type="none">
>
> *That I can xref with any other node*
>
> <field name="children" type="com.mycode.servlets.model.Node"
> collection="arraylist">
> <sql dirty="ignore" name="child_id"
> many-table="node_node_xref" many-key="parent_id" />
> <bind-xml name="terms"/>
> </field>
>
>
> *That all other objects inherit from*
>
> <!-- Mapping for Person -->
> <class name="com.myclientscode.model.Person"
> extends="com.mycode.servlets.model.Node" identity="id" cache-type="none">
>
> Any help, advice or counsel on this matter would be greatly appreciated.
>
> --
> Best Regards,
> Jim Manico
> VP Software Engineering, Codemagi Inc.
> GIAC GSEC Professional, Sun Certified Java Programmer
> [EMAIL PROTECTED]
> 808.652.3805
>
---------------------------------------------------------------------
To unsubscribe from this list please visit:
http://xircles.codehaus.org/manage_email
