HTTP context and session

In coding, we often encounter a concept: context, such as thread. currentcontext), HTTP context (httpcontext. so what is the context and what is the meaning of their existence?

 

I. Context

1: Source

It may not be traceable, but the early context concept may come from switching the CPU time slice. In the single-CPU phase, we know that although the program can simulate multiple processes (such as multiple exe) or multi-thread running, it actually reaches the CPU level and can only execute one command at the same time. The fast switch of CPU simulates multi-process execution for the program. However, for this simulation, when a process's time slice arrives or its resources are insufficient, the CPU will be transferred out, before another process starts to use the CPU, the system needs to save the execution status of the exiting process so that it can be restored on site when the time slice or resources are available. This is called context switching.

Later, we called the retained state and recovery state as context switching. HTTP context refers to this situation. The server must respond to requests from different regions, and the status of each request is retained and restored (mainly request, response, session-session, etc) HTTP context switch. is httpcontext.

For more information about the context, see: http://blog.csdn.net/shyc1922/article/details/6876412

 

2: essence of httpcontext. Current

Now, the essence of linguistics must be a static object. Why? If it is not static, we cannot access it quickly. Imagine that new httpcontext may cause misunderstanding to the programmer. The original context is re-generated every time the request is made. Of course it should not be. Why? Because the context information of this request already exists in the previous request. This is the source code of the current attribute:

If it is followed by contextbase. the HTTP context is related to the thread, this also proves from another aspect that the context is essentially a certain state of storage and switching:

 

Ii. Session

1: What is a session?

In the real world, a session is a direct object for two people. As long as the two people still exist, they can continue the conversation. In Web applications, either the client or the server is used, as long as the client is still valid, it can continue to communicate with the server,The server also knows that you are the client in Beijing., Not the Shanghai client, although there may also be clients in Shanghai that are communicating with me. So, you know that you are the client in Beijing, that is, what httpcontext does (bottom layer), and the data that the client communicates with the server (upper layer) is session data, the communication data can be stored in sessions.

 

2: Session nature

With the above understanding, we can find that the session is not the context. In fact, this understanding is correct, but the context tends to be a little more at the underlying layer, while the session tends to be a little more at the upper layer. Because the session is attached to the HTTP context, the session becomes static. So what is the nature of session:

In essence, it is an items, and it is a dictionary. If we want to implement a so-called session, we can basically implement it like this:

Class mycontent
{
Public static dictionary <string, Object> session = new dictionary <string, Object> ();
}

 

3: Session restrictions

ASP. the default session mechanism of net is to store data in the memory. When there is not enough data in the memory, the data is easy to lose, so ASP. the net engine also provides other data storage mechanisms, such as databases. It also allows us to save our own data.

 

4: Use the default session data storage mechanism

Even so, sessions are still widely used, for example, to save sessions in the business logic sense. For example, in domain-driven development, domain model objects can be stored in sessions. Because Domain Models Are stateful, they have keys that maintain their own States, which can be used by us, save the object in the session. In this way, there is no need to restore the domain object for each request. Because restoring the domain object means reading from the database and handing it over to the session, we can avoid reading from the database, as long as the object is lost, and then restore from the database.