A service on Integration Server (IS) can be set as stateful or stateless. This article aims at describing how this setting works and its effect on performance and resource usage.
IS establishes a session whenever a client connects to it. This session includes information on the user and provides a context for checking authorization of any services invoked within the session. IS uses this session to recognize that multiple separate calls from clients are actually from the same client and form part of a single session. This information can be attached to the session and later retrieved in order to persist information from one call to the next (within the same session). The information is held in memory and is accessed through the Session object.
A session is maintained between client and server through the use of HTTP cookies. When a new session is established, IS passes the session ID to the client using a cookie in the HTTP header of the service response. If the client honors that session, then it will pass the session cookie back to the IS in subsequent service calls. This allows IS to recognize that those subsequent calls are part of the same session. In many cases, especially in system-to-system interactions, clients will not honor a session cookie and will therefore not pass the cookie back to the server. This results in IS establishing a new session for every service call from such a client.
Each session takes up memory space and in a clustered environment needs to be synchronized between cluster nodes. Therefore it is best to tune session settings to minimize the build-up of unnecessary sessions.
By default, the service’s “Stateless” property is set to False, indicating that a service is Stateful.
This Stateless property applies only to top-level services and is ignored for lower-level services.
Stateful services
In a default condition (Stateless=False), IS establishes a session and passes the session ID to the client in the session cookie. After the service invocation, IS keeps the session object in memory for future calls.
The session is terminated either by the client explicitly destroying the session (e.g. by invoking wm.server:disconnect) or when the session times out after a given period of inactivity. The session timeout defaults to 10 minutes and can be configured in IS Administrator under Settings > Resources.
The session timeout indicates that if the client has no activity for more than 10 minutes and then attempts a call within the same session, then it will receive an error message (access denied) and will need to handle (catch) such a situation correctly.
If the client does not honor the session cookie and does not include it in its next request to IS, IS will establish a new session.
Stateless services
If a stateless service is invoked (Stateless=True), then IS still establishes a session, but the session is immediately terminated as soon as the top-level service completes the execution and IS does not pass a session cookie back to the client. Use of stateless services can help improve performance of an IS by releasing session resources as soon as they are no longer needed.
When to use Stateful and Stateless services?
- If your client does not honor session cookies, then it is always best to make the top level service stateless.
- If your client does honor session cookies and you need to pass information from one service called within a session to a subsequent service, then you must use a stateful service.
In other cases, you should decide based on call volumes and timeouts. If there is high volume of service calls from a single client, then there is a small performance benefit to having this all within one session (IS does not need to keep creating and destroying sessions). However, the downside is the need to be able to cope with session timeouts by the client.
Integration Server as a client
When IS is acting as a client (e.g. using pub.client:http) then by default it will honor session cookies within the same session. This is normally the case when testing services multiple times from Designer. The “newSession” input parameter to the pub.client:http service allows you to force a new session to be established by not passing a session cookie to the server.
Soudip 