Axis2 Sessions and Service Instances

In Axis2, there are four types of sessions that we talk about. Each session has a lifetime and characteristics specific to the session type. The available sessions in Axis2 can be listed as follows:

1. Request scope

2. SOAP session scope

3. Transport session scope

4. Application session scope

When we deploy a service without specifying a service scope, the service is then deployed within a request scope. Among all of the available sessions, request scope has the lowest lifespan. Lifespan is such that each and every service invocation is considered a new session. Therefore, if we deploy a service within a request scope, and send two requests to the service, there will be two sessions activated.

One of the common characteristics associated with sessions is the number of service implementation class instances. Each session gets a new service implementation class instance. So if we deploy a service in a request scope then for each and every request there will be a new session, and with it, a new service implementation class instance.

However, if we deploy a service in SOAP session scope and client sends the corresponding session id (servicegroupId), then he can stay in the same session. As a result, from the service side, the client will be interacting with the same service instance. Therefore, the number of service instances associating with a SOAP session depends on the number of SOAP sessions created.

The same story goes for transport sessions, as well. Number of service instances created for a given service depends on the number of session being created.

On the other hand, if we deploy a service in an application scope, then there will be only one session created for that service.

Author

Deepal Jayasinghe, Senior Software Engineer, WSO2. deepal AT wso2 DOT com