Re: OSCPool/EO stack management/relaunch (was: Should ERXEC get sharedEC automagically?)

29 Aug 2018

      site_archiver@lists.apple.com
Delivered-To: webobjects-dev@lists.apple.com
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gevityinc.onmicrosoft.com; s=selector1-gevityinc-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=BUgIEAVZo7qDk0F8f5rZNsWWybkVmdlbLDGv2PdEtmw=; b=dLpexuYj7/KmdhYNSI5i/0XRP+HG88GT0RlXzcCYsrFFebsD4Ppm5tNW//kV8KNzMq8UZNQflz+Cn2IlB+xphqbvZEvLUiOr0lWaUcbDXvM30t4dkWKyXQGQAsd6zEswKz6xcHJTxlWdAGnsoTXey0p7n9d4KhhpYukeljqQx/8=
Spamdiagnosticmetadata: NSPM
Spamdiagnosticoutput: 1:99
Thread-index: AQHUOhCcCiGDuXdauUezdrE/XVYZIaTOKT+AgARfAgCABCHIgP//tLGA
Thread-topic: OSCPool/EO stack management/relaunch (was: Should ERXEC get sharedEC automagically?)

EOF will reconnect if the connection to the database is lost (database
restarted, network problems, etc.).  See the EOAdaptor.Delegate method

reconnectionDictionaryForAdaptor

NSDictionary<java.lang.String,java.lang.Object>
reconnectionDictionaryForAdaptor(EOAdaptor adaptor)
Creates a new connection dictionary for the adaptor. It is responsible for
guaranteeing that the new connection dictionary is compatible with any
EODatabase that is currently using the adaptor. Note that if reconnection
succeeds, the EODatabase will continue to use its database snapshots as if
nothing had happened so the new database server should have the same data as
the original.

I am not sure that will be useful in your case.

Chuck

From: "ocs@ocs" <ocs@ocs.cz>
Date: Wednesday, August 29, 2018 at 4:54 AM
To: Chuck Hill <chill@gevityinc.com>
Cc: "webobjects-dev@lists.apple.com" <webobjects-dev@lists.apple.com>
Subject: Re: OSCPool/EO stack management/relaunch (was: Should ERXEC get
sharedEC automagically?)

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
<chill@gevityinc.com<mailto:chill@gevityinc.com>> wrote:

Finally, an easy question!

Compatible just means that
modelA.connectionDictionary().equals(modelB.connectionDictionary())

Chuck

From: "ocs@ocs" <ocs@ocs.cz<mailto:ocs@ocs.cz>>
Date: Thursday, August 23, 2018 at 7:03 PM
To: Chuck Hill <chill@gevityinc.com<mailto:chill@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: 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 <ocs@ocs.cz<mailto:ocs@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
<chill@gevityinc.com<mailto:chill@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" <ocs@ocs.cz<mailto:ocs@ocs.cz>>
Date: Tuesday, August 21, 2018 at 1:02 PM
To: Chuck Hill <chill@gevityinc.com<mailto:chill@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
<chill@gevityinc.com<mailto:chill@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" <ocs@ocs.cz<mailto:ocs@ocs.cz>>
Date: Tuesday, August 21, 2018 at 12:23 PM
To: Chuck Hill <chill@gevityinc.com<mailto:chill@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 <ocs@ocs.cz<mailto:ocs@ocs.cz>> wrote:

Chuck,

sorry, I did not describe the problem clearly enough...

On 21 Aug 2018, at 8:39 PM, Chuck Hill
<chill@gevityinc.com<mailto:chill@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" <ocs@ocs.cz<mailto:ocs@ocs.cz>>
Date: Tuesday, August 21, 2018 at 11:21 AM
To: Chuck Hill <chill@gevityinc.com<mailto:chill@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
<chill@gevityinc.com<mailto:chill@gevityinc.com>> wrote:

See er.extensions.ERXEC.useSharedEditingContext at
https://wiki.wocommunity.org/display/documentation/Explanation+of+the+defaul...

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.com@lists.apple.com<mailto:webobjects-dev-bounces+chill=gevityinc.com@lists.apple.com>
 on behalf of ocs@ocs.cz<mailto:ocs@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

   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

   This email sent to chill@gevityinc.com<mailto:chill@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

This email sent to ocs@ocs.cz<mailto:ocs@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/site_archiver%40lists...

This email sent to site_archiver@lists.apple.com