For a single session-managed PAS for OpenEdge connection, each asynchronous request is executed in the order that it is submitted, and the event procedures for those requests are executed in the same order that the requests are executed. This order is maintained by the send and response queues associated with the connection, as well as the client event queue used to raise PROCEDURE-COMPLETE events.

The send queue queues the requests that are submitted for execution by the client. The response queue queues the responses received on a given PAS for OpenEdge connection for asynchronous requests that have completed execution, but whose event procedure has not yet been executed. Finally, the client event queue queues the PROCEDURE-COMPLETE event for each completed request as it is received from the response queue.

The following figure shows how this works for an unbound session-managed application, where 1 is the first asynchronous request (AsyncRequest 1) a PAS for OpenEdge instance, 2 is the second asynchronous request (AsyncRequest 2), and so forth.

AsyncRequest refers to the execution of an asynchronous RUN statement, and EventProc refers to the execution of an event procedure in response to the PROCEDURE-COMPLETE event handled from the ABL event queue. For simplicity, the example assumes that the PAS for OpenEdge instance as only a single multi-session agent with two sessions, Session X and Session Y, to execute requests.

On this unbound session-managed connection, if an asynchronous request is submitted for execution when there is already a request executing on the application server, the new asynchronous request is queued on the send queue until all previously submitted asynchronous requests for that connection have executed. Such is the case for AsyncRequests 7, 8 and 9. The running asynchronous request (in this case, 6) was dispatched to an available server session (Session X) for execution after the immediately prior request (in this case, 5) completed execution. Note that only one session at a time executes requests for a session-managed connection, in this case Session X. However, any available session (such as Session Y) can execute the next request for an unbound connection.

As each request completes execution, the response to the request is queued on the appropriate response queue. In the previous figure, AsyncRequests 1c and 2d are next in line for execution. Each response remains in the response queue until the corresponding event procedure can be executed in the context of a PROCESS EVENTS or blocking I/O statement. In the previous figure, the PROCEDURE-COMPLETE events have fired in order, and have already executed the event procedures for AsyncRequests 1 and 2, is executing the event procedure for AsyncRequest 3. The responses for AsyncRequests 4 and 5 are still pending in the response queue.

The response to an asynchronous request can be received by the client application at any time, but the event procedure associated with that request can be run only if the application is executing a PROCESS EVENTS or blocking I/O statement. Note that the order in which the client handles pending responses for different server connections is undefined. In the previous figure, either the event procedure for AsyncRequest 1a or AsyncRequest 2a can execute first.

Note that the order in which a session-managed client handles asynchronous responses from multiple PAS for OpenEdge connections is undefined. Thus, OpenEdge guarantees that the responses from asynchronous requests on the same PAS for OpenEdge connection are handled in the order they are sent to the client. However, it does not guarantee the order in which responses are handled from multiple PAS for OpenEdge connections.