: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
l 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?)
>
> Ch
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
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
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 SE
