4 3 WAM Session Management

LANSA WAM

4.3 WAM Session Management

A user Web interaction with a server involves many requests from the same user/client to the server. Each request from a server's perspective is a unique request. The HTTP protocol is stateless and does not provide an implicit mechanism for maintaining a continuous session across multiple Web requests for the same user/client. Refer to Being Stateless for further information.

To overcome these challenges, most transactional web-based applications provide their own mechanism for session management. A WAM uses a declarative, implicit, secure session management mechanism. Session management has been designed to be as transparent as possible to the rest of the application.

Web session data or state is stored in a database on the server and is identified with a unique session key that is passed between the server and browser. Since the browser does not have a mechanism to explicitly terminate a session, a timeout mechanism is provided which expires a session once there are no more requests from the same user within a specified time period.

For more details, review the following:

4.3.1 Session Management Configuration

4.3.2 Session Key Method

4.3.3 The WEB_MAP *PERSIST Keyword

4.3.4 Session State Maintenance

4.3.5 The Mechanics of Session Management

4.3.6 WAM Session Properties

4.3.7 WAM Session Example

4.3.8 Session States

A WAM application has the facility to store session state on the server in a server independent way. To declare session state, it is necessary to set OPTIONS attribute of fields or lists to *PERSIST. Using *PERSIST ensures that whatever changes are made to those fields and lists, they are always accessible on the server once a WEBROUTINE is executed in the context of that session. Storing the actual session state in a database enables a multi-stream execution environment. Consequently, it is possible to setup and configure multiple application servers, on separate boxes, for greater scalability. Individual WEBROUTINE requests could be shared amongst all available servers. When a request is made, the session state (i.e. all the fields and lists marked OPTIONS(*PERSIST)) is reloaded from a single database into server memory before WEBROUTINE RDMLX is executed. The session state is unloaded when the WEBROUTINE exits.