Feedback
 
Did this article resolve your question/issue?

   

Your feedback is appreciated.

Please tell us how we can make this article more useful. Please provide us a way to contact you, should we need clarification on the feedback provided or if you need further assistance.

Characters Remaining: 1025

 


Article

What are the types of OpenEdge sessions

« Go Back

Information

 
Article Number000087187
EnvironmentProduct: OpenEdge
Version: 11.5 and later
OS: All supported platforms
Question/Problem Description
Where do I find more information about sessions.
Steps to Reproduce
Clarifying Information
Error Message
Defect/Enhancement Number
Cause
Resolution
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.
Workaround
Notes
References to Other Documentation:

Progress OpenEdge -> Progress Application Server for OpenEdge - > Introducing PAS for OpenEdge -> Comparing PAS for OpenEdge to the OpenEdge AppServer -> Operating modes and session types:
https://documentation.progress.com/output/ua/OpenEdge_latest/index.html#page/pasoe-intro/operating-modes-and-session-types.html

 
Attachment 
Last Modified Date12/19/2018 5:11 PM