The operating principle of session in ASP

Write a little bit larger the ASP's people know that the session this object is really useful, it can be used to record the user's private data variables, both safe and convenient. But do you really know how the session works? Maybe after you know it, you'll never be too brave to use this loving and hateful object. While the alternative is a bit cumbersome, it has to be done in the long run.

First of all, the benefit of the session is that it can be used to record the client's private data variables and not disappear within the time range. This is really an important feature, especially if a member's system has to be used. Like a member's login account, time, status, and a lot of real time data for the record ﹝ such as the ﹞ of merchandise in the user's shopping basket for the shopping system, this information is required by individual users, and usually the developer uses session records.

However, the session in ASP is made up of cookies, and the server passes all the information recorded in the session to the user's browser in the form of cookies. Usually the browser will save these cookies, whenever the user click on the link, and again with the server online, the browser will send the cookies back to the server for processing. This is the operating principle of the session, when the data volume is larger, because must be spread out and collected back, not only eat line bandwidth, efficiency is relatively low, because the Server must spend more resources to do online processing and reconfiguration of memory, such as initial action. Now you may think, "I have to use this function, I have to sacrifice the point," but this article on the one hand is to teach people to use less, on the other hand, there is an alternative, and then play, is the same Global.asa Application object.

Application is also a good record of processing temporary data, all aspects of the ability and usage are the same as the session, but in contrast, it records the information is public, that is, any user can share the variable space. Application not like session, not the data to the user, and so the next time read back online, it is directly recorded in the Server memory, relative to the efficiency of the session many.

Because the Application object is public, the first thing must do is to put a common area planning to the users, so that each user has its own area can record data to achieve the purpose of simulation session. Now there are two ways:

First, when the server is activated to initialize and allocate the user memory space, usually this practice although a server power on the first account of a lot of resources, but also eliminates the future whenever users online must do a distribution of trouble. There is a limit, however, that the maximum number of people must be limited by using this method, and since it is initialized by activation, we can only estimate a certain amount of memory space, so this method is usually used in small programs such as chat rooms.

Second, this method should be more appropriate for large applications, using dynamic allocation method, when the user first time online to the Server to start allocating resources to the users. These two simulation sessions, the goal is to reduce the session resource consumption, but after all, still cannot replace completely, we still need to use a little session, at least for the Server has been able to alleviate a lot of burden.

First programme

First we start with the implementation of the first scenario, since it is initialized application when activated, of course we have to proceed from the Global.asa:

Initialization has been completed, but how to use it? As long as we are in the user login place, the original use of the session stored information, such as account number, login time, to our established Application object can be:

' Looking for unused space

For i = 1 to Application ("Clientmax")

If application ("User_status_" & i) = 0 Then

' User temporary number

Session ("Index") = I

' Lock

Application Application.Lock

' Set to a used state

Application ("User_status_" & i) = 1 ' Put variable data

Application ("User_account_" & i) = Account

Application ("User_logtime_" & i) = Now ()

' Unlock

Application.UnLock

Exit for

End If

Next

Getting the user's dependent variable data is like the following:

Response.Write (Application ("User_account_" & Session ("Index"))

You may find that it is not to say don't use session? So why is there a session in the original code? Also said earlier, this alternative can not completely replace the session, the browser is not always with the Server online, read the page is disconnected, then how do we know the next time online or the same person? This time we have to rely on the session, we give the user a set of real-time numbering, this number is the user on the application variable space number, you can imagine that the bank has a lot of safes, you have a key, and the key is numbered, The number on the key allows clerk to lead you to your own safe. There are still improvements to this approach, but it is already sufficient for small applications.

Second programme

With regard to the previous proposal, you may also think that our custom number used the session to record, referring to the number, session object has provided a "SessionID" method. Yes, whether we want to use, the Server will automatically help each user to make a number, and this number will not repeat, as for this number is made with Session.SessionID. This number is the session will do the action, we can use it to replace our own written numbering procedures, but also to save a kung fu, even greater expansion. But basically, the first plan above has its uses, such as a limited number of chat rooms and so on small applications, the next second alternative, is for the larger system.

The number of stations per second up to hundreds of thousands of or even tens of thousands of people's Web site, the use of the previous scheme, must not be feasible. Suppose you set the upper limit to 10000, server activation will help you cut out 10,000 areas to prepare for 10,000 users, if there are 5 variables in one area, one variable occupies 32 bytes (byte), and 10,000 occupies 320000 K (320MB), and server activation Stuffed with so much rubbish into memory, efficiency is bound to be reduced by a lot before the battlefield, and although the numbers are small enough to think that your own MB will suffice, the number above is assumed to be a minimum number, plus the amount of resources the Server uses to configure memory is unknown, so only more will not be lower. Therefore, the solution is to dynamically configure the user variable space, when there is a user and Server online to cut a region out, so there is no need to configure a large memory beforehand.

The second solution is relatively simple, please discard the first solution, we do not need to move to the Global.asa, only need to change the user login and other useful places:

' Lock Applicationapplication.lock ' into variable data

Application ("User_account_" & Session.SessionID) = Account

Application ("User_logtime_" & Session.SessionID) = Now () ' Unlock Application.UnLock

Getting the user's dependent variable data is like the following:

Response.Write (Application ("User_account_" & Session.SessionID))

In the past, read a lot of books, are written on the session to eat resources to eat very fierce, try not to use, but must use the time still have to use, the book did not teach more appropriate solutions. Now when you know how to replace the session, take advantage of it! Perhaps the problem of efficiency that always bothers you can improve a lot!