Keith - (based on Walthers, 2002, 2d Ed.)
Session variables can either be dependent on cookies (_ASP.NET_SessionID created on client machine) or independent of cookies (Cookieless Sessions, in which the SessionID is embedded with the current page's URL). By default, session state relies on cookies.
Session objects are stored on the Server and reference is made to the cookie on the client side (cookies) or the Session ID embedded within the URL (Cookieless Sessions). In this way, data tables and other objects, not compatible with traditional client side cookies, can be stored. The limitation here is scalability if large objects (such as tables) are routinely put into Session.
You can enable Cookieless Sessions by altering system.web in the Web.Config file, e.g.,
Code:
<configuration>
<system.web>
<sessionState
cookieless="true"
</system.web>
</configuration>
Cookieless sessions are fully compatible with managing state in process, in a Windows service, or in a database table. There's nothing wrong with enabling cookieless sessions and storing the session data in a database table.
Limitations in Cookieless sessions is that you cannot use absolute URLs when linking between pages (every link in your aspx pages must make reference to the current page), e.g.,
<a href="mypage.aspx">Click here</a>
<a href="mydri/mypage.aspx">Click here</a>
works but...
<a href=""/mypage.aspx">Click here</a>
<a href=".../mypage.aspx">Click here</a>
does not (makes no ref to current page).
You bring up a good point though Kieth. Which one is preferred? In my case, I generally rely on cookies on the client side, my target audience is not that big.
But what if your audience is large? Perhaps many will not accept cookies. Does one use the Cookieless state?
This is a good question for some of the experts here, and I have not paid too much attention to this. Let's see what someone else has to say on the subject.