Origin
Because the HTTP protocol is stateless, after the client and the server "request-response" operation, the established connection is released, the server side is not aware of just which client access. However, some scenarios need to know the status of the client, the most typical is the landing problem, the successful landing after a period of time will not need to log in. In order to solve this problem, the server side introduces session technology, which keeps the conversation state on the server side of the technology.
Session principle
When a user opens a browser and requests a Web site, the server receives the request and allocates a memory space for the request in memory, which is called the session. A session corresponds to a request and is unique, using SessionID to represent uniqueness. The session data structure is a collection of key-value.
Tracking mechanism
- When the server side returns the client request, the SessionID is sent to the client as the value of the cookie;
- When the client asks for the server again, the locally reserved SessionID cookie is placed in the HTTP request header and sent to the server side;
- The server side receives the client request, resolves the sessionid, and obtains the corresponding session. So the server will know the status of the client.
Timeout management
The server will not be able to determine whether the current client will continue to access or whether the client is shutting down, so even if the client leaves or closes the browser, the server retains its corresponding session object.
Over time, the server accumulates a large number of session objects that are not in use and eventually causes the server to run out of memory. Therefore, the server uses a "timeout limit" method to solve the invalid session problem. If a client does not make subsequent requests within a certain amount of time, the server considers that the client has stopped the activity, ends the session with the client, and releases the sessions object. If the client sends an access request again after a time-out, the server considers it a new session.
Customizing the ASP. NET Session Provider
The following four modes are available in the session Provider provided by ASP:
1. InProc mode
This is the default session management mode of the ASP, which maintains the session within the application process.
2. StateServer mode
This is installed on the server. NET environment after a StateServer service, in the application process management session, can be multi-application between the session total.
3. SQL Server Mode
This is the hosting of the session using SQL Server. The advantage is that SQL Server can be used to deal with the massive session, outside the application process, durable, high security advantages.
4. Custom Mode
This is a custom mode, play a large space, in the case of owning provider, can use this mode to play, using a variety of data storage procedures for session management.
Below we will use the custom mode, step-by-step to implement session storage, data storage program using MONGODB. The steps are as follows:
1. Create a Mongosessionstatestoreprovider class and inherit the Sessionstatestoreproviderbase.
2. Overriding virtual methods in the Sessionstatestoreproviderbase class
3, define the serialization and deserialization interface Iserialization and implement the interface class, because the session needs to be serialized and then stored
4. Configure the Web.confg file, add the sessionstate node in the system.web node, and customize the properties of its child nodes provider
- The Name property is the current provider
- The Type property value is the Mongosessionstatestoreprovider class defined above, the dot before the namespace, the comma followed by the DLL file name
- ApplicationName Property Current application name
- connectionStringName Property MongoDB Database connection string connectionstrings node name as follows
- The Recordexception property indicates whether the exception is logged, and true if False is not.
- The journal property indicates whether recovery and persistence is turned on
- The Writeconcernlevel property indicates how the MONGO write is subsequently processed
Good, nonsense not much to say, directly on the code.
Finally, the code download, here is a sessionstatestoreprovider execution sequence flowchart can help you better understand how Sessionstatestoreprovider is implemented
MongoDB implements the ASP. NET Custom session