Overview of HTTP sessions

HTTP sessions is an industry standard feature that allows Web servers to maintain user identity and to store user-specific data during multiple request/response interactions between a client application and a Web application. HTTP sessions preserves:

The Tomcat servlet container, which is built into PAS for OpenEdge, provides HTTP sessions as the default method for preserving session and contextual information.

Since information in HTTP sessions can be accessible to a cluster of PAS for OpenEdge instances, HTTP sessions are useful for load balancing. (See Load balancing options for PAS for OpenEdge.)

To enable HTTP sessions for the APSV transport (HTTP session is automatically enabled for SOAP, REST and WEB), both enableRequestChunking and useHTTPSessions must be activated in the /conf/openedge.properties file. For example:

HTTP sessions are enabled by default in PAS for OpenEdge instances and there is nothing you need do to configure them. However, you can check these settings in an instance's openedge.properties file to ensure that HTTP sessions are enabled.

Notice that chunking must be enabled as well as HTTP sessions. Chunking is an efficient method for sending a large amount of data in a request or response when the size of the content is not known. Chunking also that all the data gets transmitted in a single post operation in the context of a single session to a single server. You can use chunking if HTTP sessions is disabled (if, for example, you only have one instance and do not require load balancing . However, you will get a startup error if chunking is disabled and HTTP sessions is enabled.

When load balancing is implemented using clusters of PAS for OpenEdge instances, HTTP sessions allows session context information to be available to all the nodes in the cluster. Therefore a single session between a client and a Web application can be maintained over any number of instances in the cluster. See Clusters and sticky sessions and Tomcat load balancingfor more information.

The Web application determines when to start and stop a session. Also, It not only determines what contextual information will be stored in the session, it determines how that information will be stored.

By default, when a Web application running on a PAS for OpenEdge instance decides to initiate a session with a client, it creates a JSESSIONID cookie that identifies the session. The cookie is sent to the client. Every time the client runs a request to that application, the cookie gets sent back to the PAS for OpenEdge instance, whose job is to identify and retrieve the stored data that is associated with the session id.

Context information required for the session is automatically saved in HTTP sessions. Again, it is up to the application to determine what needs to be saved and how to save it. Context data itself can be saved to and retrieved from HTTP sessions. Or you can save the context information externally and just save a reference to it in HTTP sessions. The latter option is more efficient when there is a large amount of data associated with the session.

In ABL for example, the SERVER-CONNECTION-CONTEXT attribute of the SESSION system handle is commonly used to set context information. If the context information can be expressed as a string of less than 32K, the attribute can be set to that value. The 32K maximum may be even less, depending on the other limitations imposed by your particular configuration. However, the more data you store in SERVER-CONNECTION-CONTEXT the more performance is likely to suffer. Therefore, the recommended practice is to store the context information in a database and use the SERVER-CONNECTION-CONTEXT attribute as a reference to the context information.

The implementation of how to store context varies widely, and depends on application requirements. For more information on how to use the SERVER-CONNECTION-CONTEXT attribute see Progress Application Server for OpenEdge: Application and Migration Development Guide and OpenEdge Development: ABL Reference.