For a single session-free PAS for OpenEdge connection, asynchronous requests are executed in no determined order, and the event procedures for those requests are executed in no determined order. Unlike requests sent over session-managed connections, which are handled sequentially, requests sent over session-free connections are handled in parallel and completed in a manner that depends entirely on available PAS for OpenEdge resources.

The send queue queues the requests that are submitted for execution by the client in the order that the client submits them. The response queue queues the responses received on a given business application connection for requests that have completed execution. Finally, the client event queue queues the PROCEDURE-COMPLETE event for each completed request as it is received from the response queue. However, it is the availability of PAS for OpenEdge resources in its session pool that determines when and how these requests are actually processed.

The following figure shows how this works for a session-free application, with nine asynchronous requests submitted on the client. In this example, the requests are assumed to be sent for a single PAS for OpenEdge instance.

For simplicity, the example assumes that the PAS for OpenEdge instance has only two ABL sessions (Session X and Session Y) to execute requests. However, the principle is the same multiple PAS for OpenEdge instances executing requests sent through a Domain Name Server (DNS) load balancer. The main difference is that multiple PAS for OpenEdge instances are likely to provide higher general availability for the business application. 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. The requests are numbered in the order they are sent from the client.

On a session-free connection, if an asynchronous request is submitted for execution when all PAS for OpenEdge resources are unavailable, the next 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 8 and 9. The most recent asynchronous request (9) is only sent to the PAS for OpenEdge instance for execution once AsyncRequest 8 has been submitted to an available session for execution. All prior asynchronous requests have completed execution (1, 2, 4, 5, and 6) or are executing in the available sessions (3 and 7).

Note that although these requests have been submitted by the client in order from 1 to 9, AsyncRequest 3 is still being executed, while AsyncRequests 4 through 6 have already completed. If this was a session-managed application, AsyncRequests 4 through 7 would still be in the send queue, waiting for 3 to complete. Because the application is session-free, AsyncRequest 3 has taken so long to complete execution in session Y that AsyncRequests 4 through 6 have already completed execution in session X and AsyncRequest 7 is still executing in session X.

Assuming that 3 completes while 7 is still running, 3's results will appear in the response queue ahead of 7 and AsyncRequest 8 will likely begin executing in session Y. Note that when this series of requests began, AsyncRequests 1 and 2 would have executed at the same time in sessions X and Y, but 2 clearly completed before 1 and passed its results back ahead of it because its results were the first to appear in the event queue.

So, while results might return faster in a session-free application, the application must be written to handle them in any order. An example might be populating a temp-table with the results of each request ordered by an index, where the order of population is therefore irrelevant.

Note, again, in the previous figure, if sessions X and Y were running in two separate PAS for OpenEdge instances accessed through a DNS load balancer, the order of completion might be exactly the same, especially if the load balancer balanced the load evenly between them. The one feature that could very well change the order of completion between the two-server and the one-server scenarios is if the two-server scenario balanced the load significantly differently between the two PAS for OpenEdge instances.