Working Set, Working Set Result Pool and the History List are heavily used structures within Strategy Intelligence Server. This document explains what these concepts are and how they are related through an illustrative set of user actions. It begins with some definitions that will also be helpful in further discussions.
Report Instance (RI)
A Report Instance (RI) is an instance of the report definition (that resides in the Metadata) within the Strategy Intelligence Server memory. One can think of the RI as the current state of the report in the Strategy Intelligence Server memory, which is used for all the manipulations by the other components of the Intelligence Server kernel. A RI is also different from a report cache in that a report cache is a serialized (binary-stream) version of the RI and a report cache, even though in memory, must be converted into a RI before it can be manipulated.
Message
A message is simply a link or a pointer to an RI in memory. A message is uniquely identified by the MessageID that is also easily identifiable as it is passed around during the client-server communications. It should be emphasized that a MessageID itself does not necessarily point to an RI at all times, thus a MessageID may be linked to a CacheID, through the CachePool, and the relation between the two will be used to instantiate the RI using the cache (whether the cache is in memory or on disk). At any given time, a message can point to, at most, two RIs. When the message is first created, it holds a reference to the Original Report Instance (ORI) and as the ORI is manipulated, for example if the different attributes are pivoted, the message starts holding references to the Last Report Instance (LRI) along with the ORI. Even though there may be numerous manipulations to follow, the message always holds pointers to LRI and ORI. The message also keeps track of the manipulations between LRI and ORI via the so-called "delta-XML" mechanism, wherein each manipulation (delta) is represented by XML.
Working Set (WS)
A Working Set (WS) is a working set of messages in memory (along with the other auxiliary objects) that are visible to one particular user session at any given time. As the definition implies, the WS is a session based structure and the references to the messages from within that user session are destroyed once the user session is destroyed along with the WS. In other words, if the same user creates multiple sessions, i.e., they log into Strategy Intelligence Server multiple times, each session will have its own WS. Working Sets are not shared across user sessions even though they might belong to the same user. There is no Working Set (WS) for a session created by the Strategy Desktop client (beginning with version 7i - 7.2.1).
History List
A History List (HL) is a repository of MessageIDs that are linked to the CacheIDs through the CachePool. Different from the WS, an HL does not contain all the messages that are created within the user's session.
Working Set Result Pool
A Working Set Result Pool(WSResultPool) is a repository of report instances across all users and all sessions. The size of the WSResultPool is governed by the Server Configuration level setting "Maximum RAM for Working Set cache (MB)."
Consider the following user-activity based workflow that illustrates the relationship between these concepts:
1. Consider that a Strategy Web user logs into the Strategy Intelligence Server. WSResultPool is a structure that exists independent of the user login/logout, but a 'User' object and a 'User Session' object are created upon the user's first login. The User session object contains a WS structure (per that session). The User object contains the History List, or the History List is loaded per the User when the user first logs in. Note also the direction of the arrows in the following figure: a User Session holds a pointer to the User but the reverse is not true. In other words, a User object does not know that it is being referred to whereas the User Session knows to which User it is referring. This figure also depicts that the HL points to the messages. If the HL of the user is not empty, the MessageIDs are loaded into memory along with the HL but do not point to any RIs. Also note that the WS has no knowledge of the message as they do not point to the RIs.
2. Now, consider that the user accesses a HL message. The message now points to the two report instances ORI and LRI (suppose that when the HL message was saved, the original message was already pointing to two RIs). The Working Set now points to the message, as illustrated below:
3. The user now executes a report without sending it to HL. A new message is created that points to the ORI for the new message and WS also points to this message:
4. The user now manipulates the report that was just executed resulting in a second report instance, namely LRI. The new message points to this LRI, as well:
5. Consider that the same user now logs in again, effectively creating a new user session. The new User Session object points to the existing User object but it has no knowledge of the other User Session. The new User Session also contains a new and different WS2 that is not related to the first WS1 created within the first User Session:
6. Since the new User Session can also see the User object and, therefore, access the HL, suppose that the user accesses the same HL message from the second session. Now the second working set WS2 is pointing to the first message, as well:
7. The user now logs out of the first session and the corresponding WS1, message2, and the RIs are destroyed, as follows:
8. The following figure illustrates is the state of the WS, WSResultPool, HL and the other objects after the user's first session is terminated:
The working set structure enables Strategy Web users to seamlessly run and manipulate the reports. One of the Strategy Web settings is depicted below:
It also affects the functioning of the WS. The setting is used to regulate the number of messages that the WS can be allowed to refer (per user session) and thereby affect the end user's experience in the following way:
Consider the following scenario in which the Strategy Intelligence Server state is as follows after a series of manipulations:
With the above setting set to 3, one of the messages, i.e., Message3, is dropped from the WS after the user executes another report:
The user now goes back three times using the browser's 'Back' button and arrives on the page that is not tied to an existing message (browser cache may allow the display of this page for which the message no longer exists):
At this point, if the end user attempts to do any manipulations on the report, they will receive the following error message:
Job expired: Report results no longer available
Now consider the similar scenario where the HL is involved. Notice that in this scenario Message3 is now also linked to an HL message, or equivalently Message3 was created by sending the report to the History List:
Upon executing a new report, Message3 is now dropped from the WS, however, it is still pointed to by the User's HL:
If the user now attempts to go back three times and manipulate the message missing from the WS, Strategy Intelligence Server manages to tie the message to the WS as it is visible through the HL and the User object to the User Session:
Note that even though the Browser cache might not have been enabled, the page with Message3 can be displayed in this particular case because of the Browser history and simply the message exists in the HL. As the report instances are held in memory, the administrators should be aware of the impact of the above settings while considering the end-user experience.
Note: It is important to mention that each separate execution of each separate report for each separate user session is a separate report instance altogether. These report instances are not shared between users.
10138
