How to transfer session data from one server to another server?

We have developed one Web Application which is running in only one ser开发者_Python百科ver. Now client needs our application be in two servers. So if one of the servers down then another server should be working. We are using sessions in our application. Now the problem is how to transfer the session data from one server to another??

You need a session server to do this.

That normally means a SQL server that will serve as one, but there are other options.

ASP.NET allows you to session information in one of three places (see list from MSDN below). Methods 2 or 3 would be good solutions to your dilemma.

1. InProc mode, which stores session state in memory on the Web server. This is the default.

2. StateServer mode, which stores session state in a separate process called the ASP.NET state service. This ensures that session state is preserved if the Web application is restarted and also makes session state available to multiple Web servers in a Web farm.

3. SQLServer mode stores session state in a SQL Server database. This ensures that session state is preserved if the Web application is restarted and also makes session state available to multiple Web servers in a Web farm.

Of course, unless you also have a redundant state machine you'll still have a single point of failure.

Move to the SQL Session state model and backend it with a SQL Server. Here's the Microsoft How-To.

Read this Maintaining Session State & Sharing Data Across Servers, Domains & the Entire Internet

What you need to do is maintain your session data in a replicated database (e.g., using SQL server), as opposed to locally on one machine.

Note that when you use this technique you will gain in reliability, but lose out in latency due to the overhead of using the database.

Look at the ScaleOut State Server. This gadget will share session state across mutliple servers so if one goes down, no sessions are lost.

There are typically a few ways to solve this:

• Run a StateServer which lets a state service handle your session data. Saves you the trip to a database, but leaves you with a single point of failure

• Put you State in SQLServer. Gives some extra load on the database. But if you have clustering you avoid having af single point of failure

• Sticky connections in a loadbalancer. The loadbalancer remembers which server, served you last time, and sends you there again. If the server in question is down, your session is lost.

• Then there are som distributed State Server products out there like NCache which lets you distribute you state service over multiple servers.