As the MSMQ transport is geared towards high numbers of concurrent users, it has been optimized with object pooling in mind. With object pooling, users share a pool of LINCEnvironment objects that know how to send messages to and from the Agile Business Suite System. Each client assumes that when it retrieves an object from the pool, it has the correct context, that is, be connected to the correct Agile Business Suite System.
Traditionally, the context of the LINCEnvironment object is automatically changed when a SwitchTo is executed. In an object pooling environment this would be invalid, as the next user of a switched object would have the wrong context, and would be trying to call Ispecs that don't exist (they would get 921 or 913 errors).
To solve this problem, when using the MSMQ transport the SwitchTo is passed out to the client to action. The client gets a new response code of 850 OK_MSMQ_SWITCH. Any SwitchTo is treated as if it contains the Bye clause. The Remote Access servers send a BYE message to the system being switched away from. In this sense, a SwitchTo is equivalent to logging off the system, and logging onto a different system.
In a non-pooled environment, the client can change the context of the
LINCEnvironment object (prefix, bundle, application, and queue), connect to the new system, and send a HI. Data in the Data clause of the Switch.To; is also passed, and the client can use that to put the new system into the correct context.
In a pooled environment, the client would release the current LINCEnvironment object back to the pool, and then obtain a new LINCEnvironment object from a different pool with the correct context. Data in the Data clause of the SwitchTo is also passed, and the client can use that to put the new system into the correct context.
Note: SwitchTo for TCP/IP connections, still works in the usual way.