amit,
have a look at this
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnaspp/html/aspnetsessionstate.asp
copying some text off the article... good article worth a read...
If you use out-of-process session storage, the session state will still be
there, ready for further use, whatever happens to the ASP.NET worker
process. If the service is paused, the data is preserved and automatically
retrieved when the service resumes. However, if the state provider service
is stopped or fails, the data is lost. If robustness is key for your
application, drop the StateServer mode in favor of SQLServer.
<configuration>
<system.web>
<sessionState
mode="SQLServer"
sqlConnectionString="server=127.0.0.1;uid=<user
id>;pwd=<password>;" />
</system.web>
</configuration>
You specify the connection string through the sqlConnectionString attribute.
Notice that the attribute string must include user ID, password, and server
name. It cannot contain tokens, such as Database and Initial Catalog,
because this information defaults to fixed names. User ID and passwords can
be replaced by integrated security settings.
How is the database created? ASP.NET provides two pairs of scripts to
configure the database environment. The scripts in the first pair are named
InstallSqlState.sql and UninstallSqlState.sql and are located in the same
folder as the session state NT service. They create a database called
ASPState and several stored procedures. The data, though, is stored in the
SQL Server temporary storage area-the TempDB database. This means that the
session data is lost if the SQL Server machine is restarted.
To work around this limitation, use the second pair of scripts. The names of
the scripts are InstallPersistSqlState.sql and UninstallPersistSqlState.sql.
In this case, an ASPState database is created, but its tables are created
within the same database and as such are persistent. When installing the SQL
Server support for sessions, a job is also created to delete expired
sessions from the session-state database. The job is named
ASPState_Job_DeleteExpiredSessions and runs every minute. Note that the
SQLServerAgent service needs to be running in order for the job to work.
Whatever mode you choose, the way of coding session state actions doesn't
change. You always work against the Session property and read and write
values as usual. Any behavioral difference is handled at a lower abstraction
layer. State serialization is perhaps the most important difference between
session modes.
