Chuck, I guess I have solved the mystery :) Looks like all what's needed is
- to set up freely the OSCPool with any number of coordinators - at the init time, to use "isolation=serializable/locking=pessimistic" in my models - and switch off the SEC (by setting it to null in my ERXEC) - when all the init work is done, I simply call EODatabaseContext.forceConnectionWithModel(model,[URL:"jdbc:FrontBase://$dbhost/$dbname/user=$user/isolation=read_committed/locking=optimistic"],ec) and that's that, it seems it works all right, for subsequently all (session-based) ECs seem to work properly with the (OSC-based) SEC, and the connexion indeed is read-committed/optimistic, as need be. There's just one small thing I am not sure of: forceConnectionWithModel re-connects “all compatible models in the model group” too. Alas the documentation does not say what a “compatible” model is — what does that mean? How does the EOF determine which models are compatible? Thanks and all the best, OC > On 22 Aug 2018, at 2:06 PM, ocs@ocs <o...@ocs.cz> wrote: > > Chuck, > > hmmm... coudn't I somehow switch off temporarily the OSCPool, so that the > initialisation code happens precisely as if there was no pool at all, and > only then, when done, the pool starts behaving as normally? Actually I could > benefit — if it is possible — from that, not only due to the SEC, but for > other reasons as well (it would help if I could run the initialisation code > against the DB in the “isolation=serializable/locking=pessimistic” mode, > switching to “isolation=read_committed/locking=optimistic” for the normal > processing). > > The init code just reads some objects from the db (including > INFORMATION_SCHEMA, which is the reason for the DB mode), checks them, > potentially updates them, and that's that — if at this moment the application > quits and immediately runs again without the init code, it would work just as > well. But for the objects in the shared EC, there's no EO which the init code > would create/fetch and a later session-based code would use anyhow. > > I might switch off the SEC for the initialisation completely: I would run the > init code using an EC with its SEC explicitly set to null, then somehow trash > the init EO stack completely and start afresh with a new one (or ones with > OSCPool) and normal session-based processing. > > Can this, i.e., > > - to begin without OSCPool and connecting to DB in the > “isolation=serializable/locking=pessimistic” mode; > - do some stuff (without SEC), save changes; > - completely trash the EO stack; > - create a new one with OSCPool connecting to DB in the > “isolation=read_committed/locking=optimistic” mode with SEC, and run happily > ever after > > be done in some cleaner way than, well, restarting the application — which > with some trickery exploiting Auto Recover in JavaMonitor might even prove > possible, but would be super-ugly and I would rather do without? > > Thanks, > OC > >> On 22 Aug 2018, at 5:11 AM, Chuck Hill <ch...@gevityinc.com >> <mailto:ch...@gevityinc.com>> wrote: >> >> That is a good question. I’ve not used the combination. There must be >> some code that uses the default instead of getting the SEC from the >> EOEditingContext. There is a lot of code in Wonder (and some in WO) that >> assumes the defaultWhatever is the only one that will ever exist. You would >> have to step into the code to see where this is happening, or enable the >> logging of stack traces of fetches. It should be a simple fix once you find >> the spot. >> >> Chuck >> >> From: "ocs@ocs" <o...@ocs.cz <mailto:o...@ocs.cz>> >> Date: Tuesday, August 21, 2018 at 1:02 PM >> To: Chuck Hill <ch...@gevityinc.com <mailto:ch...@gevityinc.com>> >> Cc: "webobjects-dev@lists.apple.com <mailto:webobjects-dev@lists.apple.com>" >> <webobjects-dev@lists.apple.com <mailto:webobjects-dev@lists.apple.com>> >> Subject: Re: Should ERXEC get sharedEC automagically? >> >> 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 <ch...@gevityinc.com >> <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" <o...@ocs.cz <mailto:o...@ocs.cz>> >> Date: Tuesday, August 21, 2018 at 12:23 PM >> To: Chuck Hill <ch...@gevityinc.com <mailto:ch...@gevityinc.com>> >> Cc: "webobjects-dev@lists.apple.com <mailto:webobjects-dev@lists.apple.com>" >> <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 <o...@ocs.cz <mailto:o...@ocs.cz>> wrote: >> >> Chuck, >> >> sorry, I did not describe the problem clearly enough... >> >> >> >> On 21 Aug 2018, at 8:39 PM, Chuck Hill <ch...@gevityinc.com >> <mailto:ch...@gevityinc.com>> wrote: >> Once an EC has objects in it, its shared EC won’t get changed if a new >> default is set. The notification is ignored. >> >> Quite, but that's not the problem. >> >> With EOEditingContext, it works like this: >> >> (i) ec created, has no sharedEC (ec.sharedEditingContext==null) >> (ii) (due to something which creates a DBContext, I believe) the default >> sharedEC is initialized; it loads the shared objects, and sends the >> notification >> (iii) ec observes the notification, and sets the default sharedEC as its own >> sharedEC (for it is still empty) >> (iv) now, ec fetches the objects — automatically giving shared ones from its >> sharedEC, which does contain them >> >> With ERXEC (and ERXEC.useSharedEditingContext=true), there's an important >> difference: >> >> (i) erxec created, immediately gets a sharedEC >> (ec.sharedEditingContext!=null). This sharedEC differs from the default >> shared EC >> (ii) (due to something which creates a DBContext, I believe) the default >> sharedEC is initialized; it loads the shared objects, and sends the >> notification >> (iii) erxec (although still empty) does nothing, it already has a sharedEC, >> different from the default one >> (iv) now, erxec fetches the objects — would automatically give shared ones >> from its sharedEC, which, alas, contains nothing (the default one does). >> >> Thanks and all the best, >> OC >> >> >> >> >> >> From: "ocs@ocs" <o...@ocs.cz <mailto:o...@ocs.cz>> >> Date: Tuesday, August 21, 2018 at 11:21 AM >> To: Chuck Hill <ch...@gevityinc.com <mailto:ch...@gevityinc.com>> >> Cc: "webobjects-dev@lists.apple.com <mailto:webobjects-dev@lists.apple.com>" >> <webobjects-dev@lists.apple.com <mailto:webobjects-dev@lists.apple.com>> >> Subject: Re: Should ERXEC get sharedEC automagically? >> >> Chuck, >> >> >> >> >> On 21 Aug 2018, at 7:50 PM, Chuck Hill <ch...@gevityinc.com >> <mailto:ch...@gevityinc.com>> wrote: >> >> See er.extensions.ERXEC.useSharedEditingContext at >> https://wiki.wocommunity.org/display/documentation/Explanation+of+the+default+properties+in+a+Wonder+project >> >> <https://wiki.wocommunity.org/display/documentation/Explanation+of+the+default+properties+in+a+Wonder+project> >> >> Thanks a lot! >> >> (Why on earth don't they mention this on the ERXEC documentation page? Oh, >> never mind.) >> >> >> >> >> Did that fix it? >> >> Well, sort of. >> >> It gets curiouser and curiouser — in other words, I must be doing something >> far wrong. >> >> When I set the “ERXEC.useSharedEditingContext” property to true, then >> >> - the newly created ERXEC gets a shared editing context immediately upon >> creation, not later upon receiving >> DefaultSharedEditingContextWasInitializedNotification; >> - and it is a different shared EC instance, not >> EOSharedEditingContext.defaultSharedEditingContext() >> - but it is EOSharedEditingContext.defaultSharedEditingContext() who reads >> in automatically all the shared EOs >> - and therefore, when fetching EOs through the ERXEC, I am still getting >> non-shared ones in the ERXEC (for its own sharedEC is empty, and thus >> EOSharedEditingContext.defaultSharedEditingContext is ignored). >> >> Can you make any sense of that? >> >> Thanks again a very big lot, >> OC >> >> >> >> >> >> >> On 2018-08-21, 9:43 AM, "Webobjects-dev on behalf of ocs@ocs" >> <webobjects-dev-bounces+chill=gevityinc....@lists.apple.com >> <mailto:webobjects-dev-bounces+chill=gevityinc....@lists.apple.com> on >> behalf of o...@ocs.cz <mailto:o...@ocs.cz>> wrote: >> >> Hi there, >> >> the EOEditing context doc pretty unequivocally says >> >> === >> By default, an editing context that has no shared editing context listens >> for DefaultSharedEditingContextWasInitializedNotifications. If a >> notification is posted while the context has no registered objects, the >> editing context sets its shared editing context to the newly initialized >> default shared editing context. >> === >> >> Should it apply for an ERXEC, too? I sort of inferred it would, but by my >> testing, it does not seem so: an ERXEC I make (through >> ERXEC.newEditingContext()) seems to adamantly stay without >> sharedEditingContext, although the notification is posted all right (I have >> observed it myself to be sure), and if there's a good ole EOEditingContext, >> it indeed duly sets its sharedEC at the time. >> >> Have I missed something of importance somewhere? The ERXEC documentation >> does not say essentially anything of the sharedEC, far as I can say: >> >> http://wonder.sourceforge.net/javadoc/er/extensions/ERXEC.html >> <http://wonder.sourceforge.net/javadoc/er/extensions/ERXEC.html> >> >> In principle, I could work around the problem by setting the sharedEC to >> all my ERXECs programmatically -- that works all right --, but it would be a >> lot of work, with a danger I overlook something somewhere and got bit in the >> tender parts by that... >> >> Thanks, >> OC >> >> _______________________________________________ >> Do not post admin requests to the list. They will be ignored. >> Webobjects-dev mailing list (Webobjects-dev@lists.apple.com >> <mailto:Webobjects-dev@lists.apple.com>) >> Help/Unsubscribe/Update your Subscription: >> >> https://lists.apple.com/mailman/options/webobjects-dev/chill%40gevityinc.com >> <https://lists.apple.com/mailman/options/webobjects-dev/chill%40gevityinc.com> >> >> This email sent to ch...@gevityinc.com <mailto:ch...@gevityinc.com> >> >> _______________________________________________ >> Do not post admin requests to the list. They will be ignored. >> Webobjects-dev mailing list (Webobjects-dev@lists.apple.com >> <mailto:Webobjects-dev@lists.apple.com>) >> Help/Unsubscribe/Update your Subscription: >> https://lists.apple.com/mailman/options/webobjects-dev/ocs%40ocs.cz >> <https://lists.apple.com/mailman/options/webobjects-dev/ocs%40ocs.cz> >> >> This email sent to o...@ocs.cz <mailto:o...@ocs.cz>
_______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
