Re: Should loading a shared object try to fetch? (was: Should ERXEC get sharedEC automagically?)
.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:564)
at com.webobjects.foundation.NSSelector.invoke(NSSelector.java:358)
at
com.webobjects.foundation.NSSelector._safeInvokeSelector(NSSelector.java:110)
at
com.webobjects.eocontrol.EOEditingContext._sendOrEnqueueNotification(EOEditingContext.java:4715)
at
com.webobjects.eocontrol.EOEditingContext._objectsInitializedInSharedContext(EOEditingContext.java:2589)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:564)
at
com.webobjects.foundation.NSSelector._safeInvokeMethod(NSSelector.java:122)
at
com.webobjects.foundation.NSNotificationCenter$_Entry.invokeMethod(NSNotificationCenter.java:588)
at
com.webobjects.foundation.NSNotificationCenter.postNotification(NSNotificationCenter.java:532)
at
com.webobjects.foundation.NSNotificationCenter.postNotification(NSNotificationCenter.java:562)
at
com.webobjects.eocontrol.EOSharedEditingContext._processRecentChanges(EOSharedEditingContext.java:569)
at
com.webobjects.eocontrol.EOEditingContext.processRecentChanges(EOEditingContext.java:1969)
at
com.webobjects.eocontrol.EOSharedEditingContext.unlock(EOSharedEditingContext.java:781)
at
com.webobjects.eocontrol.EOEditingContext.unlockObjectStore(EOEditingContext.java:4686)
at er.extensions.eof.ERXEC.unlockObjectStore(ERXEC.java:805)
at
com.webobjects.eocontrol.EOEditingContext.faultForGlobalID(EOEditingContext.java:3626)
at er.extensions.eof.ERXEC.faultForGlobalID(ERXEC.java:1210)
at
com.webobjects.eoaccess.EOUtilities.faultWithPrimaryKey(EOUtilities.java:407)
at
com.webobjects.eoaccess.EOUtilities.faultWithPrimaryKeyValue(EOUtilities.java:388)
at
com.webobjects.eoaccess.EOUtilities$faultWithPrimaryKeyValue.call(Unknown
Source)
at
org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:47)
at
org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:116)
at
org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:144)
at
cz.ocs.model.OCSEnterpriseObject.staticEOSVM(OCSEnterpriseObject.groovy:154) //
faultWithPrimaryKeyValue called
===
>
> From: "ocs@ocs" mailto:o...@ocs.cz>>
> Date: Tuesday, August 21, 2018 at 7:05 PM
> To: Chuck Hill mailto:ch...@gevityinc.com>>
> Cc: "webobjects-dev@lists.apple.com <mailto:webobjects-dev@lists.apple.com>"
> mailto:webobjects-dev@lists.apple.com>>
> Subject: Re: Should loading a shared object try to fetch? (was: Should ERXEC
> get sharedEC automagically?)
>
> Chuck,
>
> thanks again! I did not know that (well one could write a much bigger book
> than you did with just those things I do not know...)
>
> Nevertheless, there still must be some ugly fault of mine. When using
> objectWithPrimaryKeyValue, there's the superfluous fetch, but it works.
>
> When replaced by faultWithPrimaryKeyValue, I keep getting NPEs somewhere
> inside of awakeFromInsertion — at the moment, I can't really make sense of it
> :( It looks like this:
>
> ===
> == about to load 110 from 348ad293 (SEC ) // first time, there's yet no SEC...
> 4105 [main] DEBUG NSLog - Using JDBCPlugIn
> 'com.webobjects.jdbcadaptor.FrontbasePlugIn' for JDBCAdaptor@2076611420
> ... and it is being initialised here; it fetches properly all the shared EOs
> ...
> 4110 [main] DEBUG NSLog - connecting with dictionary: {username = "";
> password = ""; URL =
> "jdbc:FrontBase://localhost/SBERDAT3/user=FINServis/isolation=read_committed/locking=optimistic
>
> ";
> }
> ... ... ... the proper SQL to load all the shared objects here ... ... ...
> 4235 [main] DEBUG NSLog - === Commit Internal Transaction
> ... and here's a problem; my overridden awakeFromInsertion logs this just
> before a super.awakeFromInsertion:
> awakeFromInsertion: in
> er.extensions.eof.ERXEC@348ad293
> ... and a log _after_ super does not happen; instead, I get this:
> java.lang.Exception:
> ... ... ...
> Caused by: java.lang.NullPointerException
> at
> er.extensions.eof.ERXGenericRecord.awakeFromInsertion(ERXGenericRecord.java:512)
> at
> cz.ocs.model.OCSEnter
Re: Should loading a shared object try to fetch? (was: Should ERXEC get sharedEC automagically?)
Assuming that we are looking at the same version of ERXGenericRecord, the NPE
is from here:
EOGlobalID gid =
editingContext.globalIDForObject(this);
if (gid.isTemporary()) {
That suggests that editingContext != this.editingContext()
In other words, that the object is registered in an editing context that is
different from the parameter to the awakeFromInsertion method. Can you check
what ECs those are? I am not sure how you would get them to be different…
Also, I see two awakeFromInsertion methods in your code:
at
cz.ocs.model.OCSEnterpriseObject.super$4$awakeFromInsertion(OCSEnterpriseObject.groovy)
and
at
cz.ocs.model.OCSEnterpriseObject.awakeFromInsertion(OCSEnterpriseObject.groovy:265)
// [*]
Or that just an artifact from using Groovy?
Chuck
From: "ocs@ocs"
Date: Tuesday, August 21, 2018 at 7:05 PM
To: Chuck Hill
Cc: "webobjects-dev@lists.apple.com"
Subject: Re: Should loading a shared object try to fetch? (was: Should ERXEC
get sharedEC automagically?)
Chuck,
thanks again! I did not know that (well one could write a much bigger book than
you did with just those things I do not know...)
Nevertheless, there still must be some ugly fault of mine. When using
objectWithPrimaryKeyValue, there's the superfluous fetch, but it works.
When replaced by faultWithPrimaryKeyValue, I keep getting NPEs somewhere inside
of awakeFromInsertion — at the moment, I can't really make sense of it :( It
looks like this:
===
== about to load 110 from 348ad293 (SEC ) // first time, there's yet no SEC...
4105 [main] DEBUG NSLog - Using JDBCPlugIn
'com.webobjects.jdbcadaptor.FrontbasePlugIn' for JDBCAdaptor@2076611420
... and it is being initialised here; it fetches properly all the shared EOs ...
4110 [main] DEBUG NSLog - connecting with dictionary: {username = "";
password = ""; URL =
"jdbc:FrontBase://localhost/SBERDAT3/user=FINServis/isolation=read_committed/locking=optimistic";
}
... ... ... the proper SQL to load all the shared objects here ... ... ...
4235 [main] DEBUG NSLog - === Commit Internal Transaction
... and here's a problem; my overridden awakeFromInsertion logs this just
before a super.awakeFromInsertion:
awakeFromInsertion: in
er.extensions.eof.ERXEC@348ad293
... and a log _after_ super does not happen; instead, I get this:
java.lang.Exception:
... ... ...
Caused by: java.lang.NullPointerException
at
er.extensions.eof.ERXGenericRecord.awakeFromInsertion(ERXGenericRecord.java:512)
at
cz.ocs.model.OCSEnterpriseObject.super$4$awakeFromInsertion(OCSEnterpriseObject.groovy)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
Method)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:564)
at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:98)
... groovy stuff here ...
at
cz.ocs.model.OCSEnterpriseObject.awakeFromInsertion(OCSEnterpriseObject.groovy:265)
// [*]
at
com.webobjects.eocontrol.EOEditingContext.insertObjectWithGlobalID(EOEditingContext.java:2871)
at er.extensions.eof.ERXEC.insertObjectWithGlobalID(ERXEC.java:975)
at er.extensions.eof.ERXEC$insertObjectWithGlobalID$0.call(Unknown Source)
... groovy stuff here ...
at cz.ocs.model.OCSEnterpriseObject.staticEOSVM(OCSEnterpriseObject.groovy:164)
// the faultWith... here
===
The awake code looks simply like this:
===
void awakeFromInsertion(EOEditingContext ec) {
println "awakeFromInsertion: ${this} in ${ec}" // this one happens before the
NPE
super.awakeFromInsertion(ec) // [*]
println "supered awakeFromInsertion: ${this} in ${ec}" // we do not get this far
... ... ...
===
Alas, at the moment I have no idea at all what in my code might be the culprit
:(
Thanks and all the best,
OC
On 22 Aug 2018, at 3:14 AM, Chuck Hill
mailto:ch...@gevityinc.com>> wrote:
Yes, that makes complete sense. EOUtilities.objectWithPrimaryKeyValue is
documented to “Fetches the Enterprise Object identified by the specified
primary key value”. It will fetch. Always. It might not use the fetched
result, but you asked it to fetch so it will. The method you want is
faultWithPrimaryKeyValue. That will either resolve the object reference from
an EO already in the EC, in the shared EC, or in the snapshot cache. If all of
those fail, only then will it fetch.
And yes, the JavaDocs for faultWithPrimaryKeyValue are wrong (copied from
objectWithPrimaryKeyValue).
Chuck
From: "ocs@ocs" mailto:o...@ocs.cz>>
Date: Tuesday, August 21, 2018 at 5:15 PM
To: Chuck Hill mailto:ch...@gevityinc.com>>
Cc: "webobjects-dev@lists.apple.com<mailto:webobjects-dev@lists.app
Re: Should loading a shared object try to fetch? (was: Should ERXEC get sharedEC automagically?)
Chuck,
thanks again! I did not know that (well one could write a much bigger book than
you did with just those things I do not know...)
Nevertheless, there still must be some ugly fault of mine. When using
objectWithPrimaryKeyValue, there's the superfluous fetch, but it works.
When replaced by faultWithPrimaryKeyValue, I keep getting NPEs somewhere inside
of awakeFromInsertion — at the moment, I can't really make sense of it :( It
looks like this:
===
== about to load 110 from 348ad293 (SEC ) // first time, there's yet no SEC...
4105 [main] DEBUG NSLog - Using JDBCPlugIn
'com.webobjects.jdbcadaptor.FrontbasePlugIn' for JDBCAdaptor@2076611420
... and it is being initialised here; it fetches properly all the shared EOs ...
4110 [main] DEBUG NSLog - connecting with dictionary: {username = "";
password = ""; URL =
"jdbc:FrontBase://localhost/SBERDAT3/user=FINServis/isolation=read_committed/locking=optimistic";
}
... ... ... the proper SQL to load all the shared objects here ... ... ...
4235 [main] DEBUG NSLog - === Commit Internal Transaction
... and here's a problem; my overridden awakeFromInsertion logs this just
before a super.awakeFromInsertion:
awakeFromInsertion: in
er.extensions.eof.ERXEC@348ad293
... and a log _after_ super does not happen; instead, I get this:
java.lang.Exception:
... ... ...
Caused by: java.lang.NullPointerException
at
er.extensions.eof.ERXGenericRecord.awakeFromInsertion(ERXGenericRecord.java:512)
at
cz.ocs.model.OCSEnterpriseObject.super$4$awakeFromInsertion(OCSEnterpriseObject.groovy)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:564)
at
org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:98)
... groovy stuff here ...
at
cz.ocs.model.OCSEnterpriseObject.awakeFromInsertion(OCSEnterpriseObject.groovy:265)
// [*]
at
com.webobjects.eocontrol.EOEditingContext.insertObjectWithGlobalID(EOEditingContext.java:2871)
at er.extensions.eof.ERXEC.insertObjectWithGlobalID(ERXEC.java:975)
at er.extensions.eof.ERXEC$insertObjectWithGlobalID$0.call(Unknown
Source)
... groovy stuff here ...
at
cz.ocs.model.OCSEnterpriseObject.staticEOSVM(OCSEnterpriseObject.groovy:164) //
the faultWith... here
===
The awake code looks simply like this:
===
void awakeFromInsertion(EOEditingContext ec) {
println "awakeFromInsertion: ${this} in ${ec}" // this one happens before the
NPE
super.awakeFromInsertion(ec) // [*]
println "supered awakeFromInsertion: ${this} in ${ec}" // we do not get this far
... ... ...
===
Alas, at the moment I have no idea at all what in my code might be the culprit
:(
Thanks and all the best,
OC
> On 22 Aug 2018, at 3:14 AM, Chuck Hill wrote:
>
> Yes, that makes complete sense. EOUtilities.objectWithPrimaryKeyValue is
> documented to “Fetches the Enterprise Object identified by the specified
> primary key value”. It will fetch. Always. It might not use the fetched
> result, but you asked it to fetch so it will. The method you want is
> faultWithPrimaryKeyValue. That will either resolve the object reference from
> an EO already in the EC, in the shared EC, or in the snapshot cache. If all
> of those fail, only then will it fetch.
>
> And yes, the JavaDocs for faultWithPrimaryKeyValue are wrong (copied from
> objectWithPrimaryKeyValue).
>
>
> Chuck
>
>
> From: "ocs@ocs" mailto:o...@ocs.cz>>
> Date: Tuesday, August 21, 2018 at 5:15 PM
> To: Chuck Hill mailto:ch...@gevityinc.com>>
> Cc: "webobjects-dev@lists.apple.com "
> mailto:webobjects-dev@lists.apple.com>>
> Subject: Should loading a shared object try to fetch? (was: Should ERXEC get
> sharedEC automagically?)
>
> Even without ERXObjectStoreCoordinatorPool, there's another strange
> behaviour. I happen to be loading my objects (many of which happen to be in
> the SEC) using “EOUtilities.objectWithPrimaryKeyValue”.
>
> If the object happens to be in the SEC, I get it all right, but when I switch
> on SQL log, it looks like it is fetched anyway?!? I.e., something like this:
>
> ===
> println "== about to load $pk from $ec.identityHashString (SEC
> $ec.sharedEditingContext.identityHashString)"
> def foo=ec.sharedEditingContext.objectsByEntityName[ename].find {
> it.rawPrimaryKey==pk }
> if (foo!=nil) println " it IS pre-loaded in SEC: $foo"
> //object=EOUtilities.objectWithPrimaryKeyValue(ec,ename,pk)
>
> object=ERXEOControlUtilities.objectWithPrimaryKeyValue(ec,ename,pk,NSArray.EmptyArray,NO,NO)
> println " got $object"
> ===
>
> logs out something like
>
> ===
> == ab
Re: Should loading a shared object try to fetch? (was: Should ERXEC get sharedEC automagically?)
Yes, that makes complete sense. EOUtilities.objectWithPrimaryKeyValue is
documented to “Fetches the Enterprise Object identified by the specified
primary key value”. It will fetch. Always. It might not use the fetched
result, but you asked it to fetch so it will. The method you want is
faultWithPrimaryKeyValue. That will either resolve the object reference from
an EO already in the EC, in the shared EC, or in the snapshot cache. If all of
those fail, only then will it fetch.
And yes, the JavaDocs for faultWithPrimaryKeyValue are wrong (copied from
objectWithPrimaryKeyValue).
Chuck
From: "ocs@ocs"
Date: Tuesday, August 21, 2018 at 5:15 PM
To: Chuck Hill
Cc: "webobjects-dev@lists.apple.com"
Subject: Should loading a shared object try to fetch? (was: Should ERXEC get
sharedEC automagically?)
Even without ERXObjectStoreCoordinatorPool, there's another strange behaviour.
I happen to be loading my objects (many of which happen to be in the SEC) using
“EOUtilities.objectWithPrimaryKeyValue”.
If the object happens to be in the SEC, I get it all right, but when I switch
on SQL log, it looks like it is fetched anyway?!? I.e., something like this:
===
println "== about to load $pk from $ec.identityHashString (SEC
$ec.sharedEditingContext.identityHashString)"
def foo=ec.sharedEditingContext.objectsByEntityName[ename].find {
it.rawPrimaryKey==pk }
if (foo!=nil) println " it IS pre-loaded in SEC: $foo"
//object=EOUtilities.objectWithPrimaryKeyValue(ec,ename,pk)
object=ERXEOControlUtilities.objectWithPrimaryKeyValue(ec,ename,pk,NSArray.EmptyArray,NO,NO)
println " got $object"
===
logs out something like
===
== about to load 101 from 25673087 (SEC a7cf42f)
it IS pre-loaded in SEC:
4663 [main] DEBUG NSLog - === Begin Internal Transaction
4663 [main] DEBUG NSLog - evaluateExpression:
4664 [main] DEBUG NSLog - 1 row(s) processed
4665 [main] DEBUG NSLog - === Commit Internal Transaction
got
===
Happens even with a
“ERXEOControlUtilities.objectWithPrimaryKeyValue(...,NSArray.EmptyArray,false,false)”
instead.
Does it make any sense? I would presume that with the desired object in the
SEC, no database roundtrip should be needed (and done) at all?
Thanks and all the best,
OC
On 21 Aug 2018, at 10:02 PM, ocs@ocs mailto:o...@ocs.cz>> wrote:
Indeed! If I switch off the OSCPool, it starts to work properly.
Thanks just again!
Nevertheless, I still must be missing something of grave importance, for with
OCSPool (I use ), I would presume the SEC for the pool being currently used by
the ERXEC would load the shared objects?
It does not: the global one does automatically load the shared objects, but the
SEC-based one of ERXEC remains empty.
Note: the code in question does not run in a session context; it is performed
at launch, before the first session is created. Might that be important perhaps?
All the best,
OC
On 21 Aug 2018, at 9:42 PM, Chuck Hill
mailto:ch...@gevityinc.com>> wrote:
Are you using the ERXObjectStoreCoordinatorPool? It keeps one SEC per pool,
not one shared globally. EOSharedEditingContext.defaultSharedEditingContext()
is the global one.
Chuck
From: "ocs@ocs" mailto:o...@ocs.cz>>
Date: Tuesday, August 21, 2018 at 12:23 PM
To: Chuck Hill mailto:ch...@gevityinc.com>>
Cc: "webobjects-dev@lists.apple.com"
mailto:webobjects-dev@lists.apple.com>>
Subject: Re: Should ERXEC get sharedEC automagically?
P.S. It seems ERX completely ignores the default shared EC, using its own one.
If I try e.g., this:
===
println "The default sharedEC is
${EOSharedEditingContext.defaultSharedEditingContext()}"
6.times {
def e=ERXEC.newEditingContext()
println "EC $e gets sec $e.sharedEditingContext"
}
println "The default sharedEC still is
${EOSharedEditingContext.defaultSharedEditingContext()}"
===
it looks like this:
===
The default sharedEC is com.webobjects.eocontrol.EOSharedEditingContext@26bbe604
2005 [main] INFO er.extensions.eof.ERXObjectStoreCoordinatorPool -
initializing Pool...
2008 [main] INFO er.extensions.eof.ERXObjectStoreCoordinatorPool -
initializing Pool finished
EC er.extensions.eof.ERXEC@40e32762 gets sec
com.webobjects.eocontrol.EOSharedEditingContext@5875de6a
EC er.extensions.eof.ERXEC@7d78f3d5 gets sec
com.webobjects.eocontrol.EOSharedEditingContext@5875de6a
EC er.extensions.eof.ERXEC@f5b6e78 gets sec
com.webobjects.eocontrol.EOSharedEditingContext@5875de6a
EC er.extensions.eof.ERXEC@71926a36 gets sec
com.webobjects.eocontrol.EOSharedEditingContext@5875de6a
EC er.extensions.eof.ERXEC@48976e6d gets sec
com.webobjects.eocontrol.EOSharedEditingContext@5875de6a
EC er.extensions.eof.ERXEC@7f6874f2 gets sec
com.webobjects.eocontrol.EOSharedEditingContext@5875de6a
The default sharedEC still is
com.webobjects.eocontrol.EOSharedEditingContext@26bbe604
===
Thanks and all the best,
OC
On 21 Aug 2018, at 9:07 PM, ocs@ocs mailto:o...@ocs.cz>> wrote:
Chuck,
sorry
