Moving existing application from using Session State InProc to SQL

Discussion in 'ASP .Net' started by Alex, Aug 24, 2007.

  1. Alex

    Alex Guest

    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
     
    Alex, Aug 24, 2007
    #1
    1. Advertising

  2. Alex

    bruce barker Guest

    Re: Moving existing application from using Session State InProc toSQL

    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
    >
    >
     
    bruce barker, Aug 24, 2007
    #2
    1. Advertising

  3. 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" <> wrote in message news:...
    > 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
    >>
     
    Juan T. Llibre, Aug 24, 2007
    #3
  4. 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
    >
    >
    >
     
    =?Utf-8?B?UGV0ZXIgQnJvbWJlcmcgW0MjIE1WUF0=?=, Aug 26, 2007
    #4
  5. Alex

    Alex Guest

    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]" <> wrote
    in message news:...
    > 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
    >>
    >>
    >>
     
    Alex, Aug 28, 2007
    #5
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Sharon
    Replies:
    0
    Views:
    376
    Sharon
    Apr 20, 2004
  2. Keith-Earl
    Replies:
    1
    Views:
    418
    Alvin Bruney [MVP]
    May 3, 2004
  3. =?Utf-8?B?VlM=?=
    Replies:
    2
    Views:
    411
    John Saunders
    Jun 3, 2004
  4. Steven Spits
    Replies:
    6
    Views:
    527
    Steve C. Orr [MVP, MCSD]
    Feb 11, 2005
  5. DNB
    Replies:
    1
    Views:
    423
Loading...

Share This Page