4.3.5 The Mechanics of Session Management

There is a pre-set configurable pool of Web jobs for processing WEBROUTINE requests. A Web job currently processing a request will load the necessary state and reset the internal state, and then make itself available for the next request which may come from a different Web session altogether. The load is shared by Web jobs at the individual request level and not the session level. As a result, it is possible to have a much larger number of active browser sessions than Web jobs running.

The stateless nature of WAM execution environment has an important implication. A WAM Component's state only exists for the duration of WEBROUTINE execution. Unless fields and lists are declared as *PERSIST, their values are destroyed and not available for the next request after WEBROUTINE exit. Consequently, any other RDMLX Components instantiated during WEBROUTINE execution will be destroyed upon WEBROUTINE termination. However, any *PERSIST fields and lists, live beyond the lifetime of a request and are still available. They can span multiple WEBROUTINE requests until session termination.

Session Management Summary

Following is a summary of important features of the WAM execution environment:

• A WAM Component is a type of RDMLX Component. It can instantiate and invoke other non-visual RDMLX Components.

• Each WEBROUTINE in a WAM can be invoked from the browser. It can also be exposed via a Service Name mechanism.

• A WAM supports the concept of a Web session. The session key to identify the Web session is stored in the browser.

• When a WEBROUTINE request is made from a browser (or other type of client device), a WAM Component is created, its requested WEBROUTINE is executed, and the WAM Component is destroyed. This process reduces the server resource usage and ensures maximum scalability.

• Since WAM execution maintains state on a per-request basis, a configurable pre-defined number of Web jobs can service many Web sessions and the requests can be shared amongst multiple application server machines.

• Any data, (i.e. fields, lists, other Component state), is destroyed upon WEBROUTINE termination and is not available on subsequent request.

• Any field or list marked with OPTIONS(*PERSIST) to declare it as session state are not destroyed but stored in a database on the server. It is possible to change this data in one WEBROUTINE request and have it available for subsequent WEBROUTINE requests.

• If no requests have been made for a session within a specified timeout period, the session is deemed expired. Any further requests from the same session will result in a SessionInvalid event being triggered. An event handler for this event can be used to handle session