All Kony Fabric Posts

Deploying MobileFabric in your Environment – Part III – Session Management

Ajay Bhat - Jun 01, 2016 - Engineering

This post is Part III of a multi-part series focusing on deploying MobileFabric in your On Premise environment. In this series, Pattabhi Dasari and I discuss how to plan out your MobileFabric deployment, and share best practices. Part I details software requirements and deployment topologies, while Part II talks about sizing.

Session Management

Kony MobileFabric server supports Memcache or J2EE in-built session management. Typically Memcache is configured for Tomcat/JBoss based environments and J2EE in-built HTTP Session Management is configured for Websphere/Weblogic environments.

Memcache

Memcache is an in-memory key-value store for small chunks of arbitrary data (strings, objects.) It is a high-performance, distributed memory object caching system, generic in nature. Memcache does not support data replication across nodes.

The Kony MobileFabric Server deployed on Tomcat can be configured to talk to any number of Memcache nodes. The nodes can be located on the same or different physical machines. All the user sessions are serialized and stored in the Memcache node. This enables the Kony MobileFabric Server to be deployed in an environment where session affinity is not available.

Scenarios

Typical scenarios that may occur when we use Memcache and how it handles sessions:

S1 - Tomcat Instance is down

In this scenario, there will be no transaction failure as the session data is available in the Memcache node. The request is routed to the other Tomcat instances. The other Tomcat instances will retrieve the session data from the Memcache.

S2 - Memcache Instance is down

In this scenario, if the session data is stored on the Memcache instance, which is down, there will be a transaction failure. All the users whose session data was stored on the Memcache instance that went down, have to reinitiate the transaction.

S3 - Physical Box is down

In this scenario, if the session data is stored on one of the Memcache instances of the physical box, which is down, there will be a transaction failure. All the users whose session data was stored on the Memcache instances of the failed physical box, have to reinitiate the transaction.

J2EE In-built Session Management

J2EE based Application servers provides http based session capabilities by default. HTTP session is managed via an in-memory key-value store.

These HTTP sessions will not survive application server restarts though.

Common scenarios

S1 - WebLogic/Websphere Instance is down

In this scenario, all the users of this instance will have to reinitiate the transaction.

S2 - Physical Box is down

In this scenario, all the users of this physical box will have to reinitiate the transaction.

Note: If session replication is configured, user will not have to reinitiate the transaction for app server / physical box restart/breakdown. Session replication can be configured for small server farms like 2-10 app servers instances. Session replication will require additional CPU and a very high-speed network connection between the app server nodes.