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

[Chuck Hill]

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

reconnectionDictionaryForAdaptor

NSDictionary 
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" 
Date: Wednesday, August 29, 2018 at 4:54 AM
To: Chuck Hill 
Cc: "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 
mailto:ch...@gevityinc.com>> wrote:

Finally, an easy question!

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

Chuck

From: "ocs@ocs" mailto:o...@ocs.cz>>
Date: Thursday, August 23, 2018 at 7:03 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: 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"],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 mailto: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 no

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

[ocs@ocs]

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  wrote:
> 
> Finally, an easy question!
>  
> Compatible just means that 
> modelA.connectionDictionary().equals(modelB.connectionDictionary())
>  
> Chuck
>  
> From: "ocs@ocs" mailto:o...@ocs.cz>>
> Date: Thursday, August 23, 2018 at 7:03 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: 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
>  
> "],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 mailto: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 
>

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

[Chuck Hill]

Finally, an easy question!

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

Chuck

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

Are you using the ERXObjectStoreCoordinatorPool?  It keeps one SEC per pool, 
not one shared globally.  EOSharedEditingConte

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

[ocs@ocs]

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  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 > > 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" mailto:o...@ocs.cz>>
>> Date: Tuesday, August 21, 2018 at 1:02 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?
>>  
>> 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 > > 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: 

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

[ocs@ocs]

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  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" mailto:o...@ocs.cz>>
> Date: Tuesday, August 21, 2018 at 1:02 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?
>  
> 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  > 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