468,140 Members | 1,435 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 468,140 developers. It's quick & easy.

Moving existing application from using Session State InProc to SQL

Hello,

This is a follow-up to my earlier post about having issues with our
application pool recycling. We currently use Session State InProc, but if I
were to choose to move the existing application to SQL instead, would the
only change in the application be the SessionState setting within
web.config? I know I'd also need to setup our MS SQL database to handle
sessions (detailed in MS Article 317604), but outside of this, is there
anything else we need to worry about changing?

I've read several articles online with the pro's and con's of InProc and SQL
Session States, and honestly in our situation I think SQL might give us more
bang for our buck. Problem is the application we're using has been in
production for almost a year and is rather lengthy. Not complex per say,
but it has many pages of content, all of which require access to the Session
variables.

Just checking... Thanks,

Alex
Aug 24 '07 #1
4 1938
the main issue you may run into with an out of proc session manager, is
the what can be in session. out of proc session managers serialize the
session object to save, and use serialization to recreate the session
objects when the request starts. this means all you session object must
be serializable.

-- bruce (sqlwork.com)

Alex wrote:
Hello,

This is a follow-up to my earlier post about having issues with our
application pool recycling. We currently use Session State InProc, but if I
were to choose to move the existing application to SQL instead, would the
only change in the application be the SessionState setting within
web.config? I know I'd also need to setup our MS SQL database to handle
sessions (detailed in MS Article 317604), but outside of this, is there
anything else we need to worry about changing?

I've read several articles online with the pro's and con's of InProc and SQL
Session States, and honestly in our situation I think SQL might give us more
bang for our buck. Problem is the application we're using has been in
production for almost a year and is rather lengthy. Not complex per say,
but it has many pages of content, all of which require access to the Session
variables.

Just checking... Thanks,

Alex

Aug 24 '07 #2
re:
!this means all you session object must be serializable

As they should be, indeed.
Non-serializable objects are a PITA...and aren't efficient.

Juan T. Llibre, asp.net MVP
asp.net faq : http://asp.net.do/faq/
foros de asp.net, en español : http://asp.net.do/foros/
======================================
"bruce barker" <no****@nospam.comwrote in message news:uv**************@TK2MSFTNGP06.phx.gbl...
the main issue you may run into with an out of proc session manager, is the what can be in session. out of proc
session managers serialize the session object to save, and use serialization to recreate the session objects when the
request starts. this means all you session object must be serializable.

-- bruce (sqlwork.com)

Alex wrote:
>Hello,

This is a follow-up to my earlier post about having issues with our application pool recycling. We currently use
Session State InProc, but if I were to choose to move the existing application to SQL instead, would the only change
in the application be the SessionState setting within web.config? I know I'd also need to setup our MS SQL database
to handle sessions (detailed in MS Article 317604), but outside of this, is there anything else we need to worry
about changing?

I've read several articles online with the pro's and con's of InProc and SQL Session States, and honestly in our
situation I think SQL might give us more bang for our buck. Problem is the application we're using has been in
production for almost a year and is rather lengthy. Not complex per say, but it has many pages of content, all of
which require access to the Session variables.

Just checking... Thanks,

Alex
Aug 24 '07 #3
If you are having app pool recycling issues, the first thing you should
probably due is try to find out if they are really being caused by InProc
Session use. It could be that you have other buggy code in your app that is
causing it to recycle frequently. You also have settings in IIS that can
control the behavior.

You can set Session to ReadOnly on pages that do not need to create session
objects, and you can also eliminate Session on pages that do not use it. Both
of these will help reduce the load.
-- Peter
Recursion: see Recursion
site: http://www.eggheadcafe.com
unBlog: http://petesbloggerama.blogspot.com
BlogMetaFinder: http://www.blogmetafinder.com

"Alex" wrote:
Hello,

This is a follow-up to my earlier post about having issues with our
application pool recycling. We currently use Session State InProc, but if I
were to choose to move the existing application to SQL instead, would the
only change in the application be the SessionState setting within
web.config? I know I'd also need to setup our MS SQL database to handle
sessions (detailed in MS Article 317604), but outside of this, is there
anything else we need to worry about changing?

I've read several articles online with the pro's and con's of InProc and SQL
Session States, and honestly in our situation I think SQL might give us more
bang for our buck. Problem is the application we're using has been in
production for almost a year and is rather lengthy. Not complex per say,
but it has many pages of content, all of which require access to the Session
variables.

Just checking... Thanks,

Alex
Aug 26 '07 #4
Hi Peter and everyone else,

Can someone direct me to a white paper or MS knowledge base showing exactly
how the Session information is stored using inproc? Is it stored in RAM, in
a temp file, or what? I'm experimenting with this to see how we can better
manage the Sessions because every page the user visits needs the Session to
identify what group, language, etc they use. Also, once they select a
product to work with, it stores that product ID number in the Session
(amoung other variables) for quick reference from other parts of the site...
so the Session variables are critical for virtually every page on the
system.

As for the recycling, we actually found that a setting was set on the server
to 'recycle as needed', which has been disabled, however I need to see why
it thought a recycle was needed. We have roughly 60-70 users who use this
system concurrently, and with 20-30 items stored in the session per user,
I'd assume this can be taxing on the server to some degree. We're already
looking to upgrade the memory in the server from 2 Gigs to 4 Gigs, but I
want to educate myself on how IIS and ASP.Net store the InProc Session.
Also per my original post, I'm testing to see if using SQL is an option as
well, but given this appliation has been live for over a year and I'm still
not 100% familiar with all the code (over 50 pages make-up this site), it'll
take me some time before I've read through every line to see exactly how
this beast works.

Take care --

Alex
"Peter Bromberg [C# MVP]" <pb*******@yahoo.yohohhoandabottleofrum.comwrote
in message news:84**********************************@microsof t.com...
If you are having app pool recycling issues, the first thing you should
probably due is try to find out if they are really being caused by InProc
Session use. It could be that you have other buggy code in your app that
is
causing it to recycle frequently. You also have settings in IIS that can
control the behavior.

You can set Session to ReadOnly on pages that do not need to create
session
objects, and you can also eliminate Session on pages that do not use it.
Both
of these will help reduce the load.
-- Peter
Recursion: see Recursion
site: http://www.eggheadcafe.com
unBlog: http://petesbloggerama.blogspot.com
BlogMetaFinder: http://www.blogmetafinder.com

"Alex" wrote:
>Hello,

This is a follow-up to my earlier post about having issues with our
application pool recycling. We currently use Session State InProc, but
if I
were to choose to move the existing application to SQL instead, would the
only change in the application be the SessionState setting within
web.config? I know I'd also need to setup our MS SQL database to handle
sessions (detailed in MS Article 317604), but outside of this, is there
anything else we need to worry about changing?

I've read several articles online with the pro's and con's of InProc and
SQL
Session States, and honestly in our situation I think SQL might give us
more
bang for our buck. Problem is the application we're using has been in
production for almost a year and is rather lengthy. Not complex per say,
but it has many pages of content, all of which require access to the
Session
variables.

Just checking... Thanks,

Alex

Aug 28 '07 #5

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

2 posts views Thread by Lars Netzel | last post: by
6 posts views Thread by Chase | last post: by
13 posts views Thread by | last post: by
3 posts views Thread by trullock | last post: by
27 posts views Thread by didacticone | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.