Release 10.1A: OpenEdge Application Server:
Developing AppServer Applications

> ## Understanding the session-managed queuing model

> For a given AppServer 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 Progress 4GL 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 AppServer connection for asynchronous requests that have completed execution, but whose event procedure has not yet been executed. Finally, the Progress 4GL event queue queues the `PROCEDURE-COMPLETE` event for each completed request as it is received from the response queue.

> Figure 1–2 shows how this works, where 1a is the first asynchronous request (AsyncRequest 1a) to AppServer 1 and 2a is the first asynchronous request (AsyncRequest 2a) to AppServer 2, and so forth.

> Figure 1–2: Session-managed asynchronous request queuing

> 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 Progress 4GL event queue. These requests are further identified by 1 for the AppServer 1 connection and 2 for the AppServer 2 connection, and a letter indicating the order of the request on the client. For simplicity, the example assumes that each AppServer has only one agent to execute requests.

> On a given connection (AppServer 1 or AppServer 2), if an asynchronous request is submitted for execution when there is already a request executing on the AppServer, 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 1d and 2e. The new asynchronous request is only sent to the AppServer for execution once all prior asynchronous requests have completed execution on the AppServer. In Figure 1–2, AsyncRequests 1b and 2c are currently executing on their respective AppServers.

> As each request completes execution, the response to the request is queued on the appropriate response queue and the next request in the send queue is sent to the AppServer. In Figure 1–2, 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 Figure 1–2, the `PROCEDURE-COMPLETE` events for AsyncRequests 1a, 2a, and 2b are all pending execution of their respective event procedures.

> 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 AppServer connections is undefined. In Figure 1–2, either the event procedure for AsyncRequest 1a or AsyncRequest 2a can execute first.

> Thus, OpenEdge guarantees that the responses from asynchronous requests on the same AppServer connection are handled in order of their execution on the client. However, it does not guarantee the order in which responses are handled from multiple AppServer connections.

Copyright © 2005 Progress Software Corporation www.progress.com Voice: (781) 280-4000 Fax: (781) 280-4095