Performance-related issues for the DISCONNECT( ) method
On a state-reset or state-aware AppServer, the DISCONNECT( ) method has no significant performance impact on your client application regardless of whether there is an AppServer Disconnect procedure defined. The AppServer Disconnect procedure is run by the AppServer after the client connection is terminated and DISCONNECT( ) method execution has completed. That is, unlike other procedures executed in an AppServer session, the AppServer Disconnect procedure is run by a state-reset or state-aware AppServer concurrently with processing occurring in the client application.
For a state-reset or state-aware AppServer, you might be able to take advantage of the way the AppServer Disconnect procedure is run to improve overall application performance. When designing your distributed application, consider tasks to be performed by an AppServer that could be performed independently of the connection between the client application and the AppServer. These tasks would typically be ones where the client application does not require any information about the success or failure of the operation. Time-consuming actions are very good candidates for consideration. By moving these tasks to the AppServer Disconnect procedure, these actions can be performed concurrently with other client application processing, improving overall application performance.
On a stateless AppServer, any defined Disconnect procedure runs before the client connection is terminated. Thus, especially for frequent and short-duration connections, you probably want to ensure that the Disconnect procedure does not perform any processing that significantly delays the execution of the DISCONNECT( ) method. This can both impact the client and delay the availability of an AppServer agent.
In a session-free application (state-free operating mode), the DISCONNECT( ) method has minimal performance impact because no Disconnect procedure is executed.