Session Management Part 2

-

Session affinity

In a clustered environment, any HTTP requests associated with an HTTP session must be routed to the same Web application in the same JVM. Each server ID is appended to the session ID. When an HTTP session is created, its ID is passed back to the browser as part of a cookie or URL encoding. When the browser makes further requests, the cookie or URL encoding will be sent back to the Web server. The Web server plug-in examines the HTTP session ID in the cookie or URL encoding, extracts the unique ID of the cluster member handling the session, and forwards the request. 
Note: Session affinity can still be broken if the cluster member handling the request fails. To avoid losing session data, use persistent session management. In persistent sessions mode, cache ID and server ID will change in the cookie when there is a failover or when the session is read from the persistent store, so do not rely on the value of the session cookie remaining the same for a given session.

Session affinity and failover:

Server clusters provide a solution for failure of an application server. Sessions created by cluster members in the server cluster share a common persistent session store. Therefore, any cluster member in the server cluster has the ability to see any user’s session saved to persistent storage. If one of the cluster members fails, the user can continue to use session information from another cluster member in the server cluster. This is known as failover. Failover works regardless of whether the nodes reside on the same machine or several machines. Only a single cluster member can control and access a given session at a time.
After a failure, WebSphere redirects the user to another cluster member, and the user’s session affinity switches to this replacement cluster member. The Web server plug-in maintains a cluster member list and picks the cluster member next in the list to avoid the breaking of session affinity. From then on, requests for that session go to the selected cluster member. The requests for the session go back to the failed cluster member when the failed cluster member restarts.


Persistent session management:

By default, WebSphere places session objects in memory. Administrators should enable persistent session management when:
a)the user’s session data must be recovered by another cluster member after a cluster member in a cluster fails or is shut down.
b)The user’s session data is too valuable to lose through unexpected failure at the WebSphere node.
c)By sending cache overflow to a persistent session store, the administrator controls the number of sessions allowed in memory at any given time.
There are two ways to configure session persistence:
i)Database persistence, supported for the Web container only
ii)Mmory-to-memory session state replication using the data replication service available in distributed server environments.

All information stored in a persistent session store must be serialized.

i)Database persistence

In database persistence,This allows WebSphere to support large session objects. Also, this provides a more efficient mechanism for storing and retrieving session contents under certain circumstances.
Using a cache lets the session manager maintain a cache of most recently used sessions in memory. Retrieving a user session from the cache eliminates a more expensive retrieval from the persistent store. The session manager uses a least recently used scheme for removing objects from the cache.

Enabling database persistence:

At DB Level:
1. Create a session database.
2. Create a table for the session data.
3. In distributed environments, the session table will be created automatically for you when you define the data source for the database as the session management table.
4. Create a JDBC provider and data source for the database

 At WAS Level:
1. Select Servers → Server Types → WebSphere application servers.
2. Select the server.
3. Click Session management under the Container Settings section.
4. Click Distributed environment settings.
5. Select Database and click the Database link.
6. Enter the database information: Enter the data source JNDI name.
7. Click OK.
8. Repeat this for each server in the cluster and save the configuration changes, synchronize them with the servers, and restart the application servers.






















ii)Memory-to-memory replication:
1. Memory-to-memory replication uses the data replication service to replicate data across many application servers in a cluster without using a database.
2. it is also used to replicate dynamic cache data and stateful session beans across many application servers in a cluster.
Note: Memory-to-memory replication requires the HA manager to be active. HA manager is active by default, but can be disabled.
The memory-to-memory replication function is accomplished by the creation of a data replication service instance in an application server that communicates to other data replication service instances in remote application servers.
Server mode:Server only stores backup copies of other application server sessions. It does not send copies of sessions created in that particular server.
Client mode:In this mode, a server only broadcasts or sends copies of the sessions it owns. It does not receive backup copies of sessions from other servers.
Both mode:In this mode, the server simultaneously sends copies of the sessions it owns, and acts as a backup table for sessions owned by other application servers.
NOTE:Number of replicas:
A single replica allows you to replicate a session to only one other server. This is the default. When you choose this option, a session manager picks another session manager connected to the same replication domain with which to replicate the HTTP session during session creation. All updates to the session are replicated to that single server. This option is set at the replication domain level.

 Enabling memory-to-memory replication:
a. You have created a cluster consisting of at least two application servers.
b. You have installed applications to the cluster.

 To enable memory-to-memory replication, do the following steps:
1. Create a replication domain to define the set of replicator processes that communicate with each other.
a. Select Environment → Replication domains. Click New. and enter information in the fields.
b. Click Apply.
c. Click OK.
d. Save the configuration changes.



















2. Configure the cluster members.
Repeat the following steps for each application server:

 a. Select Servers → Server Types → WebSphere application servers.
b. Click the application server name. In this example, server1 and server2 are selected as application servers respectively.
c. Click Session management in the Container settings section.
d. Click Distributed environment settings.
e. Click on Memory-to-memory replication.
f. Choose a replicator domain.
g. Click OK.



























3. Repeat the previous steps for the rest of the application servers in the cluster.

Comments

Post a Comment

Popular posts from this blog

Session Management Part-1

-
Image
WebSphere Application Server Session Management Session support allows a Web application developer to maintain state information across multiple user visits to the application.  We will cover below points 1. HTTP session management 2. Session manager configuration 3. Session identifiers 4. Local sessions 5. General properties for session management 6. Session affinity 7. Persistent session management 1.HTTP session management: When an HTTP client interacts with a servlet, the state information associated with a series of client requests is represented as an HTTP session and identified by a session ID. Session management is responsible for managing HTTP sessions, providing storage for session data, allocating session IDs, and tracking the session ID associated with each client request through the use of cookies or URL rewriting techniques. 2.Session manager configuration: Session management in WebSphere Application Server can be defined at the follow
Read more

Understanding SSL

-
Image
Understanding SSL: There are many ways to go about creating an SSL connection between servers,  and the best one for your situation will depend upon the type of protocol you're planning to tunnel through it. As you probably know, the Secure Sockets Layer (SSL) allows the use of encryption to protect data sent via a TCP/IP connection. The most commonly used implementation of SSL is the HTTPS protocol: a secure encrypted alternative to HTTP for transferring information over the Web. Secure Sockets Layer ( SSL ) is a computer networking protocol for securing connections between network application clients and servers over an insecure network, such as the internet. Due to numerous protocol and implementation flaws and vulnerabilities, SSL was deprecated for use on the internet by the Internet Engineering Task Force ( IETF ) in 2015 and has been replaced by the Transport Layer Security ( TLS ) protocol. While TLS and SSL are not interoperable, TLS is backwards-compatible with
Read more

WebSphere Application Server

-
Image
What is WebSphere Application Server  ? WebSphere is a set of Java-based tools from IBM that allows customers to create and manage sophisticated business Web sites. The central WebSphere tool is the WebSphere Application Server (WAS), an application server that a customer can use to connect Web site users with Java applications or servlets. IBM released WebSphere Application Server 8.5 in June 2012 and 8.5.5 in June 2013 A pplication Server provides the infrastructure to host enterprise application. It handles application operation between user request to backend business application like a database, messaging, etc. Enterprise application, which is usually transactional based or heavily used, must have an application server with built-in redundancy, high availability, and performance oriented like WebSphere Application Server. Application Server usually sits between Web Server and Database or another backend like messaging, etc. Below is the typic
Read more