g-Solutions

Server Control Request Activity

Stopping Server Side Processes

The following describes a convention to enhance the control of server processing for an application client. The application client exposes a cancel button after each initiated request. Clicking the cancel button will return control back to the users on the client.

The issue is that the server-side processing of these requests are not cancelled on the server. Also user sessions and processing associated with long running were not killed on the server after the user logged out of the system.

The recommendation is that the server services support the ability to cancel server-side processing along with any database activity when a user cancels a request or logs out of the application. The following is a conceptual view of a proposed solution.

 

The idea is to have each user call initiated with a call to be brokered by a manager object (controller). Each Server method can return a reference to the server-side processing of this request (request_ref). Each server request can represent a server side thread object. The Manager can have a list of request objects grouped by users.

This request reference returned to a client can be a stub reference to a server object or a text based identifier. The request reference can be used to get the results of the request as they become available (incremental results).

 

The client can call an "interruptUserRequest" method on the Server for a process that the user wishes to cancel. The Server can use the manager to stop processing using the request reference. The Server can also use the manager to stopAll request for a user if the logout method is called.

 

For a Java implementation, a request can be implemented as a thread. The thread processing is stopped with a flag and or by calling the threads' interrupt method. Note that calling the interrupt method can be used to stop all blocking methods such as sleep, wait and computer Input/Output (IO). Interrupting IO is important in order to stop long running database transactions.

 

Pros

  • Improve user experience to display initial results as retrieved.
  • Allow users to stop transactions, maintaining data retrieved prior to stop request, and stops long running DB queries.
  • Improves overall heath of the application and database server.

Cons

  • Implementation assumed complex.