Background:
The existing company's product OA was developed using ASP earlier technology and needs to be used for data interaction with the latest ASP. NET products. Existing ASP applications often use "ASP Sessions", which is a classic built-in ASP mode, that is, temporary data storage is allowed in the Web server memory, the biggest constraint is that the session Status of ASP depends on the specific server. Another wider solution is that many Web servers may not be used for any network servers directed by requests. In fact, all WEB servers are in the same farm, so any session Status in the memory will not automatically follow the request. Each ASP server provides its own session status, unless the user returns to the unified server coincidentally, resulting in system session loss.
By using server management products such as bigip), users are forced to agree to the Web farm on the server to solve the problems caused by the server relationship in the memory ASP Session. To achieve this goal, a cookie is used on the client and on the server, allowing users to directly return to each reqeust on the same server. This restricts scalability, improves maintainability, and avoids the risk of Server failure, for example, session loss Server failure ).
The emergence of Microsoft ASP. NET technology has finally solved this problem. We can store session information to Web Server and database or other domain servers. Yes. The problem has been solved. Do we still need to use ASP code? All away? If this is done, it will take a lot of money to re-use. NET to rewrite ASP. It seems that it is still not feasible. Another better solution is to use iterative methods to partially transplant code to a new model, which is better than rewriting ASP code. In this process, if the old ASP code and the new ASP code are used.. NET code can have a common session State to maintain normal operation, so it will benefit you to better avoid risks throughout the lifecycle. the following solutions are provided to solve the problems caused by the server relationship when the classic ASP Session is used.
1. User-defined groups or using ASP/ADO scripts to directly read and write user session data to the database;
2. User-defined components directly access ASP. NET Session data;
3. Create a bridge sharing session between ASP and ASP. NET through Web Services;
In this article, we will discuss the last solution, which will also include some Web Services and ASP/ADO custom databases, and comparison with the basic performance data of the ASP Session pool... after reading it, you can choose which one to use.