REFERENCE LIBRARY
LEARNING CENTER

Process Pooling

To continue with this content, please log in with your Data Access ID or create a new account.
Cancel Data Access ID
You may not be authorized to see this content. Please contact Data Access Europe for more information.
Cancel Data Access Europe
You are not authorized to see this content.
Cancel Data Access Europe

DataFlex courses

Information

Process Pooling
Introduction (0m 50s)
Technology behind WebApps (6m 58s)
Next lesson:
When to use Web Properties
Cancel

Every Process Under Control (Process Pooling)

Lesson 1: Technology behind WebApps


  1. WebApps that run within browsers are usually based on HTTP(S) protocols. These protocols consist of messages being sent from the client to the browser, then to the server, and the server sends back a response. There is no continuous connection between the client and the server.
  2. There are two main types of HTTP requests. 
  3. GET requests: only the response contains content such as images, HTML and JavaScript
  4. POST requests: the request and the response contain content such as calls to web services, AJAX calls or to upload files
  5. When an application is accessed and used in the browser, each action that takes place causes requests to be sent to the server. The whole of those requests forms a “session.” Every session is assigned a session ID or key by the server within the first request and is stored in a cookie. The cookie is sent by the browser with each request to a specific domain, so that the server can identify which session the request belongs to.
  6. The WebApp Server runs on the server with the Microsoft Internet Information Server (IIS), and is responsible for mapping requests to the right application. For each application, the WebApp Server has a pool of DataFlex-written processes that are available to handle the requests.
  7. A request comes in through IIS. IIS forwards it to the server that passes it to an available DataFlex process to be handled. The response that is generated is then relayed back through the WebApp Server to the client via IIS.
  8. The request handling in DataFlex is accomplished with the cWebService or cWebHttpHandler class.
  9. The WebApp Server has a pool of processes available for each application. HTTP requests that come in are spread throughout the available processes to distribute the load. This means that multiple requests from a single session may be handled by different processes. Because the same process may be handling requests from different sessions, and sessions may have requests being sent to different processes, data cannot be stored in memory and assume it to be there with the next call that comes in.
  10. The WebApp Framework, which is a full stack web development framework, is built on top of the WebApp Server. The Framework is a JavaScript engine that communicates with a DataFlex Web Service. The DataFlex-written server side environment receives requests from the DataFlex Web Service. The requests are handled by the WebApp Framework classes, the response is sent back to the client, and the JavaScript engine running on the client knows how to handle the data.
  11. WebApp Framework request handling steps:
    1. Error handing is started
      • Errors are stored in a que, and at the end of the request they are sent back to the client in the response
    2. Session is validated
    3. Web property initialization is started
    4. DDO Synchronization
      • Re-finds records currently in use by open views
    5. Server actions are performed
      • Example: on-click on a button 
    6. DDO Synchronization again to store changes to records on the screen
    7. Recording of changes to web properties
      • Changes in client web properties are added to the response, and changes in server properties are stored in the database
    8. Finish error recording
      • Errors to the response
  12. The synchronization that is done is per view. This means that not all views within the application are always in synch. This is an optimization because a request usually only involves a single view. The view that is currently open is in sync and is invoking views as well. For drill-down applications, the invoking view is the view that sends the navigate forward into the current view. For model dialogs, the invoking view is the view that has opened the dialog.  
  13. DDOs and client web properties are only in sync and available for views that in sync. IsViewInSync (cWebApp) is a message that can be used to query whether a view is in sync or not.
©2024 Data Access Worldwide, all rights reserved
Privacy policy Cookies About dataaccess.com Online Documentation