The term "session" is used in multiple technologies in the OpenEdge software functionality, that is why it is always best to qualify the term "session" with the subsystem/component context that the discussion is about. The term "session" is applicable to:
a) TCP Session
b) SSL/TLS session
c) web server HTTP Session
d) AppServer client Session
e) ABL Session
The meaning of "session" can be abstracted to: "a session is a semi-permanent interactive information interchange, also known as a dialogue or a conversation, between two or more communicating endpoints for the purpose of maintaining context between one request message to another. For example: between a computer and user, an application and a server, etc. Sessions can be explicitly started and stopped by the two communicating endpoints - or terminated if they are idle for a specific period of time. When a "session" is stopped, the two endpoints can no longer communicate."
The PASOE APSV transport is equivalent to the classic AppServer's AIA adapter (web server application) and is used to transport AppServer network protocol messages in HTTP request and response messages. It is the same AppServer network messages as is used in an AppServer, AppServerDC, or AppServerS URL connection types. If a "session" times out due to inactivity (i.e. idle) the AppServer network protocol effectively disconnects the AppServer client and it must reconnect to establish a new "session".
Because AppServer network protocol connections between client and server are always point-to-point ( even in Session-Free connections ), the web server (PASOE) and APSV (aka AIA) transport work together and use HTTP "Session" to ensure that the point-to-point connection between the AppServer client (.NET) and the AppServer (i.e. the PASOE SessionManager) is maintained across multiple HTTP request/response messages. What will make some confusion is that AppServer network protocol idle timeouts are infinite by default - so hardly ever see a "session" dropped to inactivity - but it is still there.
Web servers like PASOE provide HTTP Session functionality to manage a client-server connection "session". All HTTP Session features will implement a HTTP Session idle timeout because they take up memory space and HTTP clients often disappear without closing the HTTP Session. An error message will be received “The session may have timed out", this will allow users to search for the error string. The PASOE's APSV transport uses HTTP Sessions to maintain the point-to-point AppServer network protocol connections, similar to how classic AppServer AIA adapters do but with better support for more modern network architectures. Those (PASOE) web server HTTP Sessions replace the idle timeout functionality of the AppServer network protocol "session", but retain the 30 minute idle timeout to not exhaust web server memory with HTTP Sessions that no longer have a client associated with them.
So users can be confused trying to associate the AppServer network protocol's idle timeout feature used in direct client to server TCP connections with the web server's HTTP Session idle timeout that replaces it. The "Session-Managed" or "Session-Free" semantics of the AppServer wire protocol do not apply to either classic AppServers, AIA adapters, or PASOE APSV transports.
For any user using a web server they will have to adjust its idle timeout setting to fit their use. Setting no timeout will eventually use up all of the web server's memory from clients who stop but do not disconnect and crash. Setting too long a timeout will equally use up memory and could possibly crash the web server if JVM memory is not set large enough to store HTTP Sessions until they eventually timeout and are removed from web server memory.
PASOE is a web server and it runs web applications like APSV. OpenEdge provides the option to NOT use HTTP Sessions and therefore bypass the HTTPSession idle timeout. However - to maintain the required AppServer network protocol point-to-point connections they must rely on TCP "session" point-to-point connections and MAY NOT use HTTP load balancers or elastic scaling. |
