Notes on session usage in ASP. NET

Q: If frameset is specified on the page, the sessionid of the page displayed in each frame is different in the first request. Why?
A: The reason is that your frameset is placed on an HTM page instead of An ASPX page.
In general, if the frameset Is An ASPX page, When you request a page, it first sends the request to the Web server. At this time, the sessionid is obtained, then the browser requests other pages in the frame respectively, so that the sessionids of all pages are the same, that is, the sessionid of the frameset page.
However, if you use an HTML page as a frameset page, the first request will be an HTML page. When the page is returned from the server, no session is generated, then the browser will request the pages in the frame, so these pages will generate their own sessionid, so this problem will occur in this case. When you refresh the page, sessionid will be the same, and it is the sessionid of the last request page.

Q: Can sessions of different applications be stored in different databases on the same SQL Server server.
A: Yes. See:
Fix: using one SQL database for all applications for SQL Server session state may cause a bottleneck
Http://support.microsoft.com/default.aspx? SCID = KB; en-US; 836680

Q: Can I obtain valid httpsessionstate and httpcontext objects in session_end?
A: You can obtain the httpsessionstate object in this method. You can directly use session to access the object. However, the httpcontext object cannot be obtained because the event is not associated with any request, so there is no context object.

Q: After I set enablesessionstate to "readonly", I can still modify the session value in inproc mode. Why?
A: even if the enablesessionstate is set to readonly, You can edit the session in inproc mode. The only difference is that the session will not be locked during the request process.

Q: What will happen when the session is set to cookieless?
A: When cookieless is set to true, the following constraints are imposed:
1. You cannot use absolute links on the page.
2. Some other steps are required in addition to switching between HTTP and HTTPS in the application.
If you send a link to another user, the URL contains the session ID information, so the two users share a session.

Q: Does the session provide a locking mechanism to allow sequential access to session Status values?
A: The session implements the reader/writer lock mechanism:
When the page has a writable function for the session (that is, the page has a <% @ page enablesessionstate = "true" %> flag), the session of the page holds a write lock until the request completes.
When the page has the read-only function for the session (that is, the page is marked with <% @ page enablesessionstate = "readonly" %>), the session of the page is read locked.
A read lock will block a write lock; A read lock will not block a read lock; A write lock will block all read/write locks. This is why when the same page in the two frameworks writes the same session, one of them starts to write after the other (the one that is a little faster) completes.

Q: If cookieless is used, how can I redirect an HTTP page to HTTPS?
A: try the following method:
String originalurl = "/fxtest3/SUB/foo2.aspx ";
String modifiedurl = "https: // localhost" + response. applyapppathmodifier (originalurl );
Response. Redirect (modifiedurl );

Q: What types of objects can be stored in the session?
A: This depends on the session mode. When using an inproc session, you can easily save any object. If you use the non-inproc mode, you can only save the objects that can be serialized and deserialized. If the stored objects do not support serialization, they cannot be saved to this mode (non-inproc).

Q: Why are the sessionids of each request different?
A: This problem may be caused by not saving any information in the session, that is, the session is not used anywhere in the program. After the session information is saved, the sessionid will always be related to the browser. At this time, the sessionid will not change.