Project:
View Revisions: Issue #54156 | [ All Revisions ] [ Back to Issue ] | ||
Summary | 0054156: Race-Condition - Deferred Login State Initialization During the Login Process | ||
Revision | 2023-12-18 18:09 by ablasco | ||
Description | Sometimes, the Login state requires the definition of the sessionID variable to verify whether we are inside or outside the application. During the Login load ( or refresh ), various processes (such as loading Masterdata, backendserver initialization, among others) can be executed in parallel, and the definition of sessionID is a resource that may not be defined in some cases. There are certain processes dependent on sessionID to identify that they are running within the application. (For example, the Backend Server initializes various Timeouts, such as the LogoutSession Dialog.) If the system is overloaded with other processes, most of the time it will work, establishing the sessionID variable. However, if the system is fast and lightweight ( not so common ), it may happen that the session variable resource is not defined for a condition, creating a conflict that may fail to initialize some background processes. Therefore, there is a possibility that some functionalities might not work due to a race-condition, and in cases where they do work, it is due to the overload of processes. This can be verified by slowing down the 3G throttle from Chrome Developer Tools. There may be times when the session variable is well defined during the Login process, but it should also be considered that refreshing the page can reinitialize the sessionID variable and cause a conflict. |
||
Revision | 2023-12-18 18:08 by ablasco | ||
Description | Sometimes, the Login state requires the definition of the sessionID variable to verify whether we are inside or outside the application. During the Login load ( or refresh ), various processes (such as loading Masterdata, backendserver initializion, among others) can be executed in parallel, and the definition of sessionID is a resource that may not be defined in some cases. There are certain processes dependent on sessionID to identify that they are running within the application. (For example, the Backend Server initializes various Timeouts, such as the LogoutSession Dialog.) If the system is overloaded with other processes, most of the time it will work, establishing the sessionID variable. However, if the system is fast and lightweight ( not so common ), it may happen that the session variable resource is not defined for a condition, creating a conflict that may fail to initialize some background processes. Therefore, there is a possibility that some functionalities might not work due to a race-condition, and in cases where they do work, it is due to the overload of processes. This can be verified by slowing down the 3G throttle from Chrome Developer Tools. There may be times when the session variable is well defined during the Login process, but it should also be considered that refreshing the page can reinitialize the sessionID variable and cause a conflict. |
Copyright © 2000 - 2009 MantisBT Group |