That does indeed fix the problem without difficulty. I'm going to assume it's because there are two date fields in the object, one of them is null in the database, which results in currentField tripping the problem on update of the object.
It appears that this now provides the correct behavior.
I'd still like to see the nine-mile-deep-exception problem this presents fixed, of course, but this gets me past my blocker.
Thanks.
On 28 Jul 2004, at 16:21, Gregory Block wrote:
Well, I found it.
First, a patch:
Index: main/org/exolab/castor/jdo/engine/SQLEngine.java
===================================================================
RCS file: /cvs/castor/castor/src/main/org/exolab/castor/jdo/engine/ SQLEngine.java,v
retrieving revision 1.17
diff -r1.17 SQLEngine.java
923,924c923,924
<
< if (_fields[i].tableName.compareTo(_mapTo) == 0 && !original[i].equals(currentField)) {
---
>
> if (currentField!=null && _fields[i].tableName.compareTo(_mapTo) == 0 && !original[i].equals(currentField)) {
Note that we weren't checking if currentField was null; don't know *WHY* that creates a problem, but it clearly did. That solved the NPE, leading to the actual problem...
Now, the resulting exception:
org.exolab.castor.jdo.ObjectModifiedException: Transaction aborted: Object of type com.wow.framework.dao.UserSubs
criptionService with identity 16 has been modified by a concurrent transaction (cache entry is different from dat
abase row). The following fields have been changed [actual/expected value]: (com.wow.framework.dao.UserSubscripti
onService).activation_date: [2004-07-27/2004-07-27 13:47:27.0]
at org.exolab.castor.jdo.engine.SQLEngine.store(SQLEngine.java:933)
at org.exolab.castor.persist.ClassMolder.store(ClassMolder.java:1613)
at org.exolab.castor.persist.LockEngine.store(LockEngine.java:756)
at org.exolab.castor.persist.TransactionContext.prepare(TransactionContext .java:1546)
at org.exolab.castor.jdo.engine.DatabaseImpl.commit(DatabaseImpl.java: 495)
at com.wow.framework.dao.jdo.impl.AbstractJDOLoader.release(AbstractJDOLoa der.java:69)
at com.wow.framework.dao.jdo.impl.DAOFactory.updateUser(DAOFactory.java: 457)
at com.wow.framework.dao.impl.PluggableDAOFactory.updateUser(PluggableDAOF actory.java:252)
at com.wow.framework.dao.User.update(User.java:107)
at com.wow.webapp.pageComponents.registration.TermsAndConditionsPageCompon ent.init(TermsAndConditionsPage
Component.java:91)
On 28 Jul 2004, at 15:57, Gregory Block wrote:
java.lang.NullPointerException
at org.exolab.castor.jdo.engine.SQLEngine.store(SQLEngine.java:924)
at org.exolab.castor.persist.ClassMolder.store(ClassMolder.java:1613)
at org.exolab.castor.persist.LockEngine.store(LockEngine.java:756)
at org.exolab.castor.persist.TransactionContext.prepare(TransactionContex t.java:1545)
at org.exolab.castor.jdo.engine.DatabaseImpl.commit(DatabaseImpl.java: 495)
at com.wow.framework.dao.jdo.impl.AbstractJDOLoader.release(AbstractJDOLo ader.java:69)
at com.wow.framework.dao.jdo.impl.DAOFactory.updateUser(DAOFactory.java: 457)
at com.wow.framework.dao.impl.PluggableDAOFactory.updateUser(PluggableDAO Factory.java:252)
at com.wow.framework.dao.User.update(User.java:107)
at com.wow.webapp.pageComponents.registration.TermsAndConditionsPageCompo nent.init(TermsAndConditionsPage
Component.java:91)
Looking at it, lock.invalidate doesn't get called because it's neither an ObjectModifiedException nor a PersistenceException - thinking that's the culprit...
As for what's causing that NPE? Not a clue. Wish I knew, as it's driving me nuts. However, it gives a stream of completely unrelated errors when it dies, that's for sure. Again, there was a constraints violation (would be nice if I could tell castor, somehow, that when an integer value is 0, it should instead use null...), but this particular instance isn't related to that particular problem. Don't know quite what the problem is yet, of course...
-----------------------------------------------------------If you wish to unsubscribe from this mailing, send mail to
[EMAIL PROTECTED] with a subject of:
unsubscribe castor-dev
-----------------------------------------------------------If you wish to unsubscribe from this mailing, send mail to
[EMAIL PROTECTED] with a subject of:
unsubscribe castor-dev
----------------------------------------------------------- If you wish to unsubscribe from this mailing, send mail to
[EMAIL PROTECTED] with a subject of:
unsubscribe castor-dev
