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:
Cancel

Every Process Under Control (Process Pooling)

Lesson 5: User Data

  1. Parts of the web application that are for a specific user need to be initialized with each request. The OnSessionPropertiesSet iN the session manager is usually used for this. This is done after the session is validated and it is known if the user is logged in or not. If logged in the identity of the user is known. This means data from the WebAppUser table can be used to initialize local properties or to set global constraints (SQL Filters). For example, this would be done in multi tenancy applications with the OnSessionPropertiesSet.
  2. Revisiting the overview of request handling of the WebApp Framework, the session validation step first validates the session and then triggers the OnSessionPropertiesSet. This is where user specific events would be initialized. This is before the web properties system is initialized, meaning that web properties cannot be used at this point. If web properties are needed, OnSynch WebApp event that is fired during the DDO synchronization. It is fired before the DDO synchronization process has done anything, so it can be used to make global filters.
  3. This sample code for a muti-tenant application shows, OnSessionPropertiesSet being implemented within the session manager. The WebApp user table has a field called ‘iTenantId.’ The data will be constrained based on the tenant ID. At the end of the procedure, a global SQL filter is defined that constrains ‘Album’ table on the specific tenant. The tenant ID is stored in a regular property. The property can be used later in the request handling to determine the current tenant. 
  4. This is safe to do because OnSessionPropertiesSet is called for each request that comes in, so initializing regular properties here is valid.


CONCLUSION

  • Running in the debugger is not 100% realistic because it only runs a single process and session
    • It is recommended to test process pooling without the Debugger running
  • Debugger is recommended for stepping through source code
  • Have pbShowAllRefindErrors set to true in the test environment
  • Emulate multiple sessions by opening multiple browser sessions
  • Running the Debugger can cause issues because it runs WebApp.exe under the current user. The WebApp server runs WebApp.exe under the system account.
    • This can be problematic because of differences in regional settings and rights
  • Cross-session contamination issues are caused by data stored in memory between requests
    • Can be solved by using web properties or by initializing for each separate operation or request