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
Next lesson:
Record buffers

Every Process Under Control (Process Pooling)

Lesson 2: When to use Web Properties

When to use Web Properties? Before that question can be answered, session data first needs to be understood.

Session data is data that is specific to a current session. Therefore, data can be unique for each user even if they are logged in at the same time. An example of session data is a record ID of a record currently showing on the screen. It can also be data that the user entered into the application that is not yet stored in the database. Anything that can be different between different users and sessions is ‘session data.’

DataFlex properties are stored in memory. When the value of a property is set, its value is stored in the memory of the process. Due to there likely being multiple processes running, each process has its own version of that value. Properties cannot be used to store data between requests for a single session because processes get messages from different sessions. The properties do look persistent in the Debugger because it can only run a single process at a time, and testing is usually done with a single session. (Server) Web properties should be used for storing session data because they are synchronized by the Framework between the sessions. 


  1. Note: The OrderEntry sample data will be used throughout the demonstration.
  2. Process Explorer from Sysinternals (can be downloaded from the Microsoft website) is an application that functions as an extended Task Manager, and shows parent and children processes in a tree-view.
  3. For this demonstration is shows, that all WebApp processes are children of the WebAppServer process, and that there are three applications, each with two processes, running. 
  4. From the Web Application Administrator (Studio Top Menu >> Tools Menu >> Web Application Administrator) the same three applications are shown.
  5. Disabling the WebOrder and WebOrderMobile applications from the Administrator also stops the processes in Process Explorer. 
  6. Incrementing the pool size of the Process Pooling application starts a third process. The processes can also be viewed within the Administrator.
  7. Client and Server messages are also shown. The number of messages does not correspond with the number of HTTP requests because a single HTTP request can cause multiple messages to be sent within the WebApp Server. The messages shown represent messages sent from the end point to the process for WebApp Server.
  8. Running the application and logging in shows in Process Explorer that the third process handled the login request. Next, a view was opened, and the first process handled the loading of the view.   
  9. The view is to illustrate that regular properties do not maintain their state between the different requests. In this view a form is used that allows a value to be entered and a ‘Remember’ button that stores the value in the psRememberValue property. There is a ‘Display’ button that displays the value of the psRememberValue property in an info box. 
  10. Saving a value in the application with the ‘Remember’ button shows that the second process handled the OnClick. Clicking the ‘Display’ button initially does not return the value because it is being handled by the third process.
  11. Doing so again also does not return the value because it was handled by the first process. A third attempt does return the value because the value was initially saved by the second process. This demonstrates that regular properties cannot be used to store values between requests because of process pooling.
  12. Starting a second session in the browser would cause problems and is referred to as “Session Contamination.” The value saved was not specific to that session it was specific to the process. 
  13. This is solved by making the property a WebProperty value. Add code to…
    • Add the metatag, “WebProperty” and set it to be a server web property
      • { WebProperty = Server }|
    • Change the “Set” to “WebSet” and specify the object name because web properties do not support delegation
      • WebSet psRememberValue to oWebMainPanel sVal
    • Change “Get” to “WebGet” and specify the object name
      • WebGet psRememberValue of oWebMainPanel to sVal
  14. Saving, recompiling the application, and returning the application shows that now after a value is saved it is returned regardless of which process the request goes to.
  15. If a second session were to be started it would have its own version of the value saved.
  16. Types of Web Properties that are available:
    • { WebProperty = Client }
      • Client WebProperty - stored on the client in a JavaScript variable. They are returned as a response to a request. Once changed at runtime they will be sent back and forth with each request between client and the server. They are expensive and insecure. Their main purpose is to communicate with the user interface.
    • { WebProperty = Server }
      • Server WebProperty – stored in the database. By default they have the same lifespan as a Client WebProperty, which means they are gone as soon as the page is reloaded. They are identified by a unique identifier that is stored in a Client WebProperty. 
    • { WebProperty = Server Session }
      • Sever session WebProperty – stored in the database. They are attached to the session key, and live as long as the session lives.
  17. When should WebGet and WebSet be used?
  18. With Client WebProperties they are used to configure the user interface, so when objects are defined the properties are set to their initial value.
  19. When a WebProperty is used inside a procedure, WebGet and WebSet should almost always be used with the exceptions of…
    • End_Construct_Object
    • OnLoad
  20. Important – WebGet and WebSet can only be used on web properties. Regular properties should be used for objects that are not WebOjects.
  21. Session aware properties need to be initialized every time an object is used within a specific request. Nearly every operation within the Framework is a separate request. Examples: OnClick, OnFocus and OnKey.