Re: OSCPool/EO stack management/relaunch (was: Should ERXEC get sharedEC automagically?)
Re: OSCPool/EO stack management/relaunch (was: Should ERXEC get sharedEC automagically?)
- Subject: Re: OSCPool/EO stack management/relaunch (was: Should ERXEC get sharedEC automagically?)
- From: "ocs@ocs" <email@hidden>
- Date: Wed, 29 Aug 2018 13:54:47 +0200
Thanks a lot!
Incidentally, is there somewhere a clean set of rules when might EOF decide to
re-connect using the model CD?
What I mean is
(a) I set up the CD to contain some settings (e.g., “isolation=read_committed”
in URL)
(b) I force this to be used through forceConnectionWithModel, overriding the
URL to “isolation=serializable”
(c) I perform the init work
(d) at end of which I reconnect, again using forceConnectionWithModel, this
time without an override, so that “read_committed” applies.
Far as my testing goes, this works.
Nevertheless, may I be sure that during (c), EOF would never happen to
reconnect by itself, using the CD from the model? Should I perhaps instead of
the above, to keep at the safe side, do uglier, but perhaps more robust
(a) set up the CD to contain temporary settings (“isolation=serializable” in
URL)
(b) either use forceConnectionWithModel without an override, or just let EOF to
connect automatically;
(c) do the init work
(d) at end of which change the CD in all models to “isolation=read_committed”,
and reconnect using forceConnectionWithModel without an override
? Thanks!
OC
> On 27 Aug 2018, at 5:48 AM, Chuck Hill <email@hidden> wrote:
>
> Finally, an easy question!
>
> Compatible just means that
> modelA.connectionDictionary().equals(modelB.connectionDictionary())
>
> Chuck
>
> From: "ocs@ocs" <email@hidden <mailto:email@hidden>>
> Date: Thursday, August 23, 2018 at 7:03 PM
> To: Chuck Hill <email@hidden <mailto:email@hidden>>
> Cc: "email@hidden <mailto:email@hidden>"
> <email@hidden <mailto:email@hidden>>
> Subject: Re: OSCPool/EO stack management/relaunch (was: Should ERXEC get
> sharedEC automagically?)
>
> 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
>
> <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 <email@hidden <mailto:email@hidden>> 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 <email@hidden
> <mailto:email@hidden>> 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" <email@hidden <mailto:email@hidden>>
> Date: Tuesday, August 21, 2018 at 1:02 PM
> To: Chuck Hill <email@hidden <mailto:email@hidden>>
> Cc: "email@hidden <mailto:email@hidden>"
> <email@hidden <mailto:email@hidden>>
> 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 <email@hidden
> <mailto:email@hidden>> 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" <email@hidden <mailto:email@hidden>>
> Date: Tuesday, August 21, 2018 at 12:23 PM
> To: Chuck Hill <email@hidden <mailto:email@hidden>>
> Cc: "email@hidden <mailto:email@hidden>"
> <email@hidden <mailto:email@hidden>>
> 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 <email@hidden <mailto:email@hidden>> wrote:
>
> Chuck,
>
> sorry, I did not describe the problem clearly enough...
>
>
>
>
> On 21 Aug 2018, at 8:39 PM, Chuck Hill <email@hidden
> <mailto:email@hidden>> 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" <email@hidden <mailto:email@hidden>>
> Date: Tuesday, August 21, 2018 at 11:21 AM
> To: Chuck Hill <email@hidden <mailto:email@hidden>>
> Cc: "email@hidden <mailto:email@hidden>"
> <email@hidden <mailto:email@hidden>>
> Subject: Re: Should ERXEC get sharedEC automagically?
>
> Chuck,
>
>
>
>
>
> On 21 Aug 2018, at 7:50 PM, Chuck Hill <email@hidden
> <mailto:email@hidden>> 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=email@hidden
> <mailto:webobjects-dev-bounces+chill=email@hidden> on behalf
> of email@hidden <mailto:email@hidden>> 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 (email@hidden
> <mailto:email@hidden>)
> Help/Unsubscribe/Update your Subscription:
>
>
> This email sent to email@hidden <mailto:email@hidden>
>
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Webobjects-dev mailing list (email@hidden
> <mailto:email@hidden>)
> Help/Unsubscribe/Update your Subscription:
>
> This email sent to email@hidden <mailto:email@hidden>
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden