I think I found a bug in Castor's rollback feature, but I would like some
confirmation as to my conclusions. I am currently using v.0.9.2.
I am getting the following stacktrace :
java.lang.NullPointerException
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:669)
at org.exolab.castor.persist.LockEngine.load(LockEngine.java:359)
at
org.exolab.castor.persist.TransactionContext.load(TransactionContext.java:55
4)
at
org.exolab.castor.persist.QueryResults.fetch(QueryResults.java:219)
at
org.exolab.castor.jdo.engine.OQLQueryImpl$OQLEnumeration.hasMore(OQLQueryImp
l.java:569)
at
org.exolab.castor.jdo.engine.OQLQueryImpl$OQLEnumeration.hasMore(OQLQueryImp
l.java:552)
The set method for my Class "LWService" that causes this exception is :
public void setUpdSubjectId( int updSubjectId ) {
this.updSubjectId = updSubjectId;
}
The NullPointerException happens when the database field corresponding to
this method is null. It seems that this happens since the method's type is
a primitive. This is all fine. However, when I catch this and try to do a
rollback, an IllegalStateException is thrown from
LockEngine.TypeInfo.assure() saying :
"java.lang.IllegalStateException: Transaction
org.exolab.castor.jdo.engine.TransactionCont
extImpl@45809e does not hold the read lock:
com.activate.business.service.LWService/1000/333 -/- OBJECT:
[Ljava.lang.Object;@34faeb!"
This is caught in line 1326, but does nothing with it:
} catch ( Exception except ) {
// maybe we should remove it, when castor become stable
}
As a consequence, the ObjectLock is never removed from the HashMap of
"locks" in LockEngine.TypeInfo and the same NullPointerException is thrown
on every load of that object thereafter even if I go back and fix the
database so that the field no longer has a NULL value. The only way to fix
this is restart the VM and reinitialize the LockEngine which is kept in the
static HashTable of DatabaseRegistries.
I am currently developing a SalesOrder System and restarting the VM is not
an option.
It seems that I can fix it in TransactionContext.rollback() in line 1326 by
doing the following in the catch block:
} catch ( Exception except ) {
// maybe we should remove it, when castor become stable
// if exception thrown from revertObject or releaseObject,
may
// not remove object from locks so explicitly release locks
here.
try {
entry.engine.releaseLock( this, entry.oid );
} catch ( Exception e ) {
// if it breaks here, can't do anything
}
}
However, I'm not sure whether this is ok to do or whether more needs to be
done to fix this bug. Can I get some feedback on my fix?
Thanks.
Charles Im
-----------------------------------------------------------
If you wish to unsubscribe from this mailing, send mail to
[EMAIL PROTECTED] with a subject of:
unsubscribe castor-dev
