In this section: |
Semiplexing provides the developer with the ability to control which connections within an application are linked and which are not. This enables the developer to establish a true physical server connection where absolutely necessary, and yet issue sub-connections to the same process where appropriate. The initial SCB allocation will always represent a real connection to a server. Subordinate SCBs can be used to control specific SQL statements issued to that server on the same physical connection.
If an application requires a truly separate context to control independent transactions, it may wish to exploit semiplexing. This will enable an application to send up a COMMIT WORK on a specific connection without affecting other open connections to the server, and yet conserve resources where appropriate.
The following figure illustrates multiplexed and non-multiplexed connections to servers.
When an application request is sent and received by the server, the server transforms from listening mode to processing mode. It will not return to listening mode until the complete request has been processed. This means that any subsequent requests to the same server on the same physical connection are queued and will not be heard by the server until the prior request has been completed.
The following figure illustrates the listening mode and the processing mode in the application-server communication.
If a request for data on a server connection is sent and then a second request is sent to the same server on another (multiplexed) connection, before the data from the first request has been processed, all the data from the first request must be delivered to the client and held by the API before the second request can be sent.
To implement semiplexing, a physical connection to a server must be established by the API with multiplexing set to OFF (EDA_VAR_NO_MPLEX (127)). This creates a server instance, which controls the unit of work. The standard EDACONNECT call establishes the initial link, constructs an SCB, and sends a message to the server to start an instance.
The SCB returned by the EDACONNECT call behaves exactly as SCBs behave in prior EDA API versions. Specifically, its status field is valid following the call, and the SCB can be used to exchange information with the server instance.
Semiplexing actually begins with the next call to EDACONNECT. This call carries a parameter list specific to the semiplex situation.
Upon return, a status of EDA_SUCCESS informs the application that the SCB is ready to exchange information with the server instance started in the initial call.
An SQL COMMIT WORK sent to either of these SCBs will commit transactions on both. If a completely independent transaction context is required, another physical EDACONNECT call will establish an independent link to the server.
Note: Any actions processed to customize the environment in the first physical connection must be repeated for each real connection to maintain the same server context (for example, file allocations).
The API does not distinguish between the semiplexed SCBs and the actual connection SCB used initially to connect to the server. The order in which the connections are terminated (disconnected) is unimportant. The last SCB disconnected will trigger the actual disconnect from the server.
| iWay Software |