Using SQL Server for ASP.Net session state
What is session state?
A session is defined as the period of time that a unique user interacts with a Web application. Session state is a collection of objects, tied to a session are stored on a server.
Why use SQL?
Once you start running multiple web servers for the same web site, the default asp.net session state, InProc, is no longer useful, as you cannot guarantee that each page request goes to the same server. It becomes necessary to have a central state store that every web server accesses.
SQL Server offers you centralized storage of a session state in a Web farm. It also offers the transactional capabilities that provide reliability to most relational database systems. You can use SQL Server to save a session. This process is not as efficient as InProc and StateServer mode, because you must store the information in a different process or on a different server. However, this option may be more efficient than using the aspnet_state service, depending on the actual workload and the database configuration. Once you start saving session state to a SQL database it will also persist through web server restarts and reboots.
For reliability you should consider storing session state for a web farm on a SQL cluster.
Creating the database
- Start Query Analyzer, connected to the server you want to use for state storage.
- Open and execute InstallSqlState.sql script file. By default, InstallSqlState.sql is located in one of the following folders;
system drive\ Windows\ Microsoft.NET\ Framework\version\
- If you are using trusted connections to connect to your server, you must change ownership of the state database to sa after creation. In Query Analyzer run
use ASPState
exec sp_changedbowner 'sa','true' - If you are using SQL authentication create a user and password for session state to use. At a minimum this user should havepermissions to execute the stored procedures in the ASPState database. You will have to manually set these, or if you're feeling dangerous, give the state user dbo rights to ASPState.
Configuring ASP.Net
To switch ASP.Net to use SQL you must update the <sessionState> element of your application's Web.config file as follows;
- Set the mode attribute of the <sessionState> element to SQLServer.
- Set the sqlConnectionString attribute to specify the connection string to your SQL Server
For example
<sessionState
mode="SQLServer"
sqlConnectionString="data source=server;user id=uid;password=pwd"
cookieless="false" timeout="20" />
If you specify integrated security/trusted connections in the database connection string (ie. "trusted_connection=true", or "integrated security=sspi"), you cannot use impersonation in asp.net, as your database connection will then run the context of the impersonated user, which will not have rights to the state database. You can, of course grant connections to that user context. KB 326606 has more details.
If you are configuring session state to be stored on a cluster you must manually override the .net machine keys on each server. KB 323262 has more details.
Configuring SQL2000 SP3
So, you have created the database, you've created the user, given it rights to all the stored procedures in the ASPState database, you've up to date with patches, Windows, IIS SQL, and you connect to your web site...
SELECT permission denied on object 'ASPStateTempApplications', database 'tempdb', owner 'dbo'.
INSERT permission denied on object 'ASPStateTempApplications', database 'tempdb', owner 'dbo'.
SELECT permission denied on object 'ASPStateTempApplications', database 'tempdb', owner 'dbo'.
SP3 for SQL 2000 adds a new security feature, disabled by default, cross-database ownership chaining (see KB 810474 for details). When this feature is disabled, ASP.Net session state stops working.
To reconfigure SQL 2000 SP3 for ASP.net session state you must run
use master
go
EXEC sp_configure 'Cross DB Ownership Chaining', '0';
RECONFIGURE
GO
Now restart your SQL server, then run
use master
go
EXEC sp_dboption 'ASPState', 'db chaining', 'true'
go
Timeouts under heavy load
If your web servers are under heavy load it may be useful to increase the time out for session state access. You can add the stateNetworkTimeout attribute to the sessionState settings in web.config and machine.config
<sessionState stateNetworkTimeout="15" />
If a Web server or a state server is under stress and cannot complete session accesses on time, event ID 1072 and event ID 1076 may be logged in the event log.
Caveats when using SQL session state
Using SQL is slower than using InProc session state. When storing basic data types (string, int, etc), ASP.Net can take 10%-25% longer to store their values. Complex types take even longer. Of course because you are connecting to a separate server it does use bandwidth on your network.
When using SQL Server mode, objects stored in session state are serialised and deserialised when a request is processed. So any objects which do not support serialisation cannot be stored in session state. In ASP.Net v1.0 a bug means that attempting to store a non-serialisable object does not throw an error, and so will probably pass unnoticed.
For session state to be maintained across different web servers in a web farm (the main reason for moving session state to SQL), the Application Path of the website (For example \LM\W3SVC\2) in the IIS Metabase should be identical in for all the web servers in the web farm. Microsoft's KB 325056 details this problem.
If you wish to persist session state through SQL server reboots you must follow the instructions in KB 311209 to move the session state tables from tempdb to the ASPState database.
Other resources
Peter Bromberg's Session State FAQ
KB 317604 HOW TO: Configure SQL Server to Store ASP.NET Session State
which cannot be easily readable
by persons having
semi-blind eye-sights!!!!
why!!!
The page has some design problems. In the T-SQL code, some of the text is black, just like the page background! Highlighting the T-SQL reveals the hidden text.
<sessionState mode="SQLServer" sqlConnectionString="data source=server;user id=sa;password=sa" cookieless="false" timeout="20" ></sessionState>
It showing error
Parser Error Message: It is an error to use a section registered as allowDefinition='MachineToApplication' beyond application level. This error can be caused by a virtual directory not being configured as an application in IIS.
How cud I sort it out.
My application uses a SQL Session State Server in a load balanced environment with heavy loads. My application is called very often (Aprox. 7000 users simultaneously). I sparatically get a timeout problem with the application and have to restart IIS. The w3wp.exe preocess is using up a lot of memory and 100% CPU. Would this be a problem with the SQL State Server?
Thanks in advance....
This might help resolve your problem..
http://msmvps.com/blogs/greglow/archive/2007/02/04/improving-asp-net-session-state-database-performance-by-reducing-blocking.aspx#544414
You can find some good articles at
http://chiragrdarji.wordpress.com/2007/04/20/aspnet-session-state-management-using-sql-server/
PLZ tell me how can i done this job.
http://www.faqfront.com/document/sql-server-session-state
Simple and easy to understand.
Simple; objects have to be serialised before they pass out of process to either the asp.net session server or the database, this takes time.
And if you're using a database then that database round trip introduces another set of processing. Database calls aren't cheap!
I doubt it, the provider only takes a server name, so it will assume a database name of ASPSTATE; I'm not sure you'd want to either; littering your own database with the session tables strikes me as messy!
Interesting once. Yes, you could put a global exception handler at the global.asax, there's an Application_Error event you could handle inside that, as an exception handler of last resort.
I don't think that you see a session state specific exception, you'd just see normal SQL exceptions; but it's probably enough to get you going.
I want to share session to another web application in same server. do you know how to do that ?
0. Make sure all your classes/objects being added to the session are serialized.
1. Create your own ASPState database
2. Give ownership to system adminstrator
2. Run the install....sql
3. May receive 1 error saying an object existis. Ignore that.
4. Create another user
5. Give dbo setting and add to ASPState
6. Use this user's login to connect through sqlConnectionstring in sessionState under web.config
Check it out http://www.alachisoft.com.