Hello there,
from the moment I've switched to using a new OSC for my background thread ECs,
I am occassionally getting weird NPEs, like e.g., this one:
===
Caused by: java.lang.NullPointerException
at
com.webobjects.eocontrol.EOCustomObject.changesFromSnapshot(EOCustomObject.java:595)
at
com.webobjects.eocontrol.EOCustomObject$changesFromSnapshot$6.callCurrent(Unknown
Source)
at
org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCallCurrent(CallSiteArray.java:49)
at
com.webobjects.eocontrol.EOCustomObject$changesFromSnapshot$6.callCurrent(Unknown
Source)
at
cz.ocs.model.OCSEnterpriseObject.fixArchivedButReallyUnchangedItemsFromSnapshot(OCSEnterpriseObject.groovy:938)
at
cz.ocs.model.OCSEnterpriseObject.validateForSave(OCSEnterpriseObject.groovy:980)
at
com.webobjects.eocontrol.EOCustomObject.validateForUpdate(EOCustomObject.java:1446)
at
er.extensions.eof.ERXGenericRecord.validateForUpdate(ERXGenericRecord.java:1215)
at
com.webobjects.eocontrol.EOEditingContext.validateTable(EOEditingContext.java:2271)
at
com.webobjects.eocontrol.EOEditingContext.validateChangesForSave(EOEditingContext.java:3020)
at
com.webobjects.eocontrol.EOEditingContext._prepareForPushChanges(EOEditingContext.java:3249)
at
com.webobjects.eocontrol.EOEditingContext.saveChanges(EOEditingContext.java:3179)
at er.extensions.eof.ERXEC._saveChanges(ERXEC.java:1179)
at er.extensions.eof.ERXEC.saveChanges(ERXEC.java:1102)
at er.extensions.eof.ERXEC$saveChanges$7.call(Unknown Source)
...
===
where my “validateForSave” and “fixArchivedButReallyUnchangedItemsFromSnapshot”
looks like this:
===
void fixArchivedButReallyUnchangedItemsFromSnapshot {
NSDictionary ss=this.editingContext().committedSnapshotForObject(this)
NSDictionary d=this.changesFromSnapshot(ss) // <=== this is line 938 ===
if (d.count) ... blah blah ...
}
void validateForSave {
super.validateForSave()
fixArchivedButReallyUnchangedItemsFromSnapshot() // <=== this is line
980 ===
}
===
and never ever used to NPE before, when I used simply
“ERXEC.newEditingContext()” inside of my thread (but that, of course, did lock
EOF stack while saving, and if there were thousands imported objects, it caused
other threads to wait for way too long).
Now, I wonder -- might the reference the EC keeps its OSC in be actually weak
one? For my particular code would indeed bring havoc if it is:
===
class ImportCSVTask extends ERXLongResponseTask.DefaultImplementation {
...
def editingContext
...
def performAction {
...
editingContext=ERXEC.newEditingContext(new EOObjectStoreCoordinator())
...
}
}
===
I must admit I considered it self-evident the reference would be strong; but
now I'm starting to doubt. Might this be the culprit?
If not (of course I've meantime added a property to be triple-sure), what the H
might cause that? (Actually I doubt this could be, for it does happen even when
I pepper my code by System.gc()'s heavily.)
Note: alas I can't “simply test”, for the problems happen intermittently;
namely, they never happened on my testing site here, they occur only on the
production server :(
Thanks,
OC
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list ([email protected])
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to [email protected]
