D
dbeavon
Guest
Thank you very much for all the thorough answers. I think they have cleared up a lot of confusion. There should be a whitepaper or, better yet, a youtube animation that describes the type of mechanism that is used to connect an OE database to its remote ABL client/server sessions. That would help to make sense of the many startup parameters, and the way they interoperate with each other as a team. My question was asked in the context of our PASOE sessions that are connecting remotely to the OE database. I was trying to make sure that my remote sessions would have efficient access to the database and wouldn't encounter too many bottlenecks. I've been using "shared memory" connections for a long time but I'm somewhat new to client-server. One thing that didn't really "click" for me until I actually watched it happen myself was the way in which a ABL session in PASOE becomes partnered and permanently "married" to a _mprosrv process on the remote database server. The _mprosrv process on the database server will be used for the life of the ABL session in PASOE. Given the flexible and dynamic relationship that a HTTP session in PASOE has to the related ABL sessions (ie. both to the MS-agent process and its underlying ABL sessions), I thought that the ABL session would *also* have an very dynamic relationship to the back-end database, and would move around from "server" to "server" over time. To me this is the type of thing that is implied by such terms as "broker" and "server". But that does *not* appear to be the case at all. The "broker" only seems to interact with the ABL session connection *once* - at the point where the session is first started. At that time the broker "marries" the ABL session to an _mprosrv process for *LIFE* (until the process on one side or the other has ended). In the event that the _mprosrv partner is a bad one - ie it happens to be co-habited by some other greedy connections - then the ABL session used by PASOE will be SOL. This is because the database broker won't ever move that ABL session to an alternate server which might be less busy. In the best-case scenario (where PASOE is concerned), there will be an entire _mprosrv that will be dedicated to a *single* PASOE session connection (REMC/PASN) so that it will always be highly responsive, and there will be no unexpected bottlenecks from any other random database requests. IE. It should be a monogamous marriage between the ABL session from PASOE and the _mprosrv process. This is especially true given that PASOE is probably supporting a very heavy workload , and is already distributing the workload and processing it concurrently (across its various agents and sessions). Thanks again for all the help. For those of you in the USA, have a happy Thanksgiving.
Continue reading...
Continue reading...