We were previously performing our own "pseudo-polymorphism" (by wrapping
our classes and throwing exceptions when we detected extended objects,
which was slow (of course), but its in a tomcat webapp, so we didnt
notice the hit too much anyway).
We'll probably revert back to our old behaviour for the moment, but
having our wrappers there is an extra level of complexity we could very
happily do without atm.. ;)
(means going back to 0.9.7, as our old queries trigger this problem
etc).
at least we're not an isolated issue - whats the jira issue# ? I think I
found a similiar issue based on the timestamp, but couldnt find one to
do with this directly. I'm interested in seeing a working test case, cos
I can't seem to get happening.
//chris
On Tue, 2005-10-04 at 09:38 -0400, Nick Stuart wrote:
> Yep, was going to bet that it was dealing with polymorphism. Whats
> your usuage of polymorphism and did you change anything in your code
> to use the new features in 0.9.9?
>
> I found that trying to use the new features in .9.9 it would behave a
> lot like what you are seeing (a bug report is already open for this),
> but I could still switch back to my old code it everything worked
> fine. I'm currently using .9.9 now with out issues and using extended
> classes, although not to their full extent because of this bug.
>
> -Nick
>
> On 10/2/05, Chris Hoy Poy <[EMAIL PROTECTED]> wrote:
> > In tracing back the castor source, we've noted the following:
> >
> > The exception is thrown in ClassMolder.load(ClassMolder.java:625)
> >
> > for ( int i = 0; i < _fhs.length; i++ ) {
> > fieldType = _fhs[i].getFieldType();
> > switch (fieldType) {
> > case FieldMolder.PRIMITIVE:
> > case FieldMolder.SERIALIZABLE:
> > case FieldMolder.PERSISTANCECAPABLE:
> > case FieldMolder.ONE_TO_MANY:
> > case FieldMolder.MANY_TO_MANY:
> > -> _resolvers[i].load(tx, oid, proposedObject, accessMode,
> > fields[i]);
> > break;
> > default:
> > throw new PersistenceException("Unexpected field type!");
> > }
> > }
> >
> >
> > the exact issue is that fields is different to resolvers and _fhs.length,
> > such that (fields.length != resolvers.length) && (fields.length !=
> > _fhs.length).
> >
> >
> > Something happens to _fhs between the proposedObject.setFields being
> > called, and this function (ClassMolder.load) being called.
> >
> > This appears to be due to something in the new polymorphism - The object
> > in question is an extended class.
> >
> > Has anyone else experienced this issue? we're experiencing issues in
> > reproducing the problem, as it is quite inconsistent.
> >
> > --
> > //chris
> >
> > <quote who="Chris Hoy Poy">
> > > Goodmorning all,
> > >
> > > We updated to Castor-0.9.9, with java 1.5.0_5.
> > >
> > > We're starting to see this exception in ClassMolder.load (which I
> > > understand was recently heavily modified etc):
> > >
> > >
> > > java.lang.ArrayIndexOutOfBoundsException: 15
> > > at org.exolab.castor.persist.ClassMolder.load(ClassMolder.java:625)
> > > at org.exolab.castor.persist.LockEngine.load(LockEngine.java:368)
> > > at
> > > org.castor.persist.TransactionContext.load(TransactionContext.java:713)
> > > at
> > > org.exolab.castor.persist.QueryResults.fetch(QueryResults.java:232)
> > > at
> > > org.exolab.castor.jdo.engine.OQLQueryImpl$OQLEnumeration.hasMore(OQLQueryImpl.java:584)
> > > at
> > > org.exolab.castor.jdo.engine.OQLQueryImpl$OQLEnumeration.hasMore(OQLQueryImpl.java:567)
> > > at
> > > au.com.mpl.xeder.entity.DBObjectFactory.OQLFetchObjectList(DBObjectFactory.java:364)
> > >
> > >
> > > I'm currently putting together a test case for this, but its fairly
> > > complex so it might take me a while (time constraints and so forth).
> > >
> > > The worst bit is that the problem appears to be fairly random, so it might
> > > something to do with our locking modes.. also the part where it happens
> > > might sometimes result in us hitting the castor code to load certain
> > > components (in the same thread) fairly rapidly (but always in the
> > > read-only mode). (although they will be made using the OQL query, rather
> > > then db.load).
> > >
> > >
> > > Any ideas? Been through the JIRA, found a couple of older entries that
> > > might be related, but doubtful if its been rewritten.
> > >
> > > then again, it could just be the way we are using castor as well ;) hard
> > > to say.
> > >
> > > Has anyone else seen this issue?
> > >
> > >
> > > Cheers;
> > >
> > > --
> > > //chris
> > >
> > >
> > >
> > >
> > > -------------------------------------------------
> > > If you wish to unsubscribe from this list, please
> > > send an empty message to the following address:
> > >
> > > [EMAIL PROTECTED]
> > > -------------------------------------------------
> > >
> > >
> > >
> >
> >
> >
> > -------------------------------------------------
> > If you wish to unsubscribe from this list, please
> > send an empty message to the following address:
> >
> > [EMAIL PROTECTED]
> > -------------------------------------------------
> >
> >
>
> -------------------------------------------------
> If you wish to unsubscribe from this list, please
> send an empty message to the following address:
>
> [EMAIL PROTECTED]
> -------------------------------------------------
>
>
--
Chris Hoy Poy <[EMAIL PROTECTED]>
-------------------------------------------------
If you wish to unsubscribe from this list, please
send an empty message to the following address:
[EMAIL PROTECTED]
-------------------------------------------------
