Context Management (Magic xpa 3.x)
When you start the first Rich Client task, it runs in its own context. The context logs the state of the task from the moment it is activated until the moment it is terminated. Each context is assigned its own unique Context ID.
When you start a Parallel task, a new context is created, with its own new Context ID. Child tasks of the parallel task will be opened in that same context (unless the Child task is also set to run in parallel, in which case it will open yet another new context).
Each context is isolated from the others. The task tree, database cursors, SetParam data, and data manipulation statements are all tracked individually for each context.
Magic xpa tracks the activity in each context. The server will identify each client request as belonging to a specific context. Information about which tasks and subtasks are open, database cursors, and data manipulation statements, are all maintained for each context.
|
Note:
|
Once a context is created on a Magic xpa engine, all the requests from the client will always reach the same engine.
When using external HTTP load balancer, you need to ensure stickiness between the client and the server – that is the ability of the load balancer to direct requests from each client to the Web server in which the initial request was created. To support this, each RIA request contains a header named MgxpaRIAglobalUniqueSessionID. This header keeps the same unique value in each HTTP request of a given end-user session. The header contains a different unique value for each client instance. External HTTP load balancers can use this to support stickiness.
|
The context information kept on the server side requires memory resources. To relieve the server from having to keep numerous contexts that might use too many system resources, a timeout can be set for the context.
The Context Inactivity Timeout setting can be found at Options\Settings\ Environment\Server. This setting determines the time interval in which the client is checked for inactivity. Context inactivity is defined as an absence of client/server interaction during the life of a Rich task.
The Context Inactivity Timeout is set in 10ths of a second. The default setting is 864000 (24 hours).
When the context timeout is reached, the context is cleared from the server. By setting a reasonable timeout, you can prevent abandoned contexts from stacking up on your server.
When a Rich Client task is invoked from the Studio, the Context Inactivity Timeout is infinite.
