Q: Why isn’t Session_End fired when I call Session_Abandon?
A: First of all, Session_End event is supported only in InProc mode. In order for Session_End to be fired, your session state has to exist first. That means you have to store some data in the session state and has completed at least one request
Q: Why does the SessionID remain the same after the Session times out or abandoned?
A:Even though the session state expires after the indicated timeout period, the session ID lasts as long as the browser session. What this implies is that the same session ID can represent multiple sessions over time where the instance of the browser remain the same.
Q: Does session state have a locking mechanism that serialize the access to state?
Session state implements a reader/writer locking mechanism:
- A page (or frame) that has session state write access (e.g. <%@ Page EnableSessionState=”True” %>) will hold a writer lock on the session until the request finishes.
- A page (or frame) that has session state read access (e.g. <%@ Page EnableSessionState=”ReadOnly” %>) will hold a reader lock on the session until the request finishes.
- Reader lock will block a writer lock; Reader lock will NOT block reader lock; Writer lock will block all reader and writer lock.
- That’s why if two frames both have session state write access, one frame has to wait for the other to finish first.
Code Samples for Storing Data in Session objects
1. Storing String in Session Objects
Session["MyData"] = TextBox1.Text;
2. Storing Objects in Session Objects
Client oClient = new Client();
Session["MyData"] = oClient;
Code Samples for Retrieving Data in Session Objects
1. Retrieving String in Session Objects.
TextBox1.Text = Session["MyData"].ToString();
2. Retrieving Objects in Session Objects
Client oClient = (Client)Session["MyData"]
