amit,
have a look at this
http://msdn.microsoft.com/library/de...ssionstate.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.
--
Regards,
HD
"Amit Agarwal" <am**********@idealake.com> wrote in message
news:%2****************@TK2MSFTNGP09.phx.gbl...
hi Hermit,
this is amit
my site is on two webservers
configured both in sqlserver mode.
I am not able to maintain state as i do not have identical Appname in the
ASPState database for the site.
how to make the appname in DB same
i guess some changes in the IIS metabase
THx
amit agarwal
"Hermit Dave" <he************@CAPS.AND.DOTS.hotmail.com> wrote in message
news:%2****************@TK2MSFTNGP11.phx.gbl... yes when you implement it you will come across some issues... please do
post it here cause we do have a lot of gurus around and should be able help
you in case you have a problem....
yes i am from india though not in india any more... was in bombay for
almost 2 years before i moved to london.
--
Regards,
HD
"Amit Agarwal" <am**********@idealake.com> wrote in message
news:ub**************@TK2MSFTNGP10.phx.gbl... hi,
hermit
thx for ur reply
i have been to these urls
have u practically went on to implement this case..
coz when u practically start
lot of hiccups arise..
anyway thx
r u from mumbai
"Amit Agarwal" <am**********@idealake.com> wrote in message
news:e1**************@TK2MSFTNGP12.phx.gbl...
> Hi,
> this is amit from india.
>
> can anyone help regarding effective session management over a
webfarm >
> precautions to take,etc.
>
> thanks
>
>
