sessionState mode="StateServer" vs. "InProc"

Discussion in 'ASP .Net' started by April, Jan 23, 2009.

  1. April

    April Guest

    I have a Windows 2000 Server (SP4) with .NET Framework 1.1 (with hotfixes)
    installed, along with .NET Framework 2

    I have a Delphi .DLL that interfaces with several .aspx files as part of a
    member database. Each .aspx file contains categorized properties about
    members. The first page is named profile1.aspx, the second page
    profile2.aspx and so forth. NEXT and PREVIOUS buttons allow the user to
    move back and forth.

    For some unknown reason, the session state is being lost as the member/user
    clicks the NEXT and PREVIOUS buttons. My web.config file contained the
    following lines:

    <sessionState
    mode="InProc"
    stateConnectionString="tcpip=127.0.0.1:42424"
    sqlConnectionString="data source=127.0.0.1;user id=sa;password="
    cookieless="false"
    timeout="20"
    />

    Out of desperation we changed the mode from "InProc" to "StateServer" and
    then turned ON the "ASP.NET State Service" from within the Services MMC
    snap-in. After making this change, the session state is preserved between
    pages.

    Might anyone know why session state would always be lost as the user moved
    from .aspx to .aspx page with mode="InProc"?

    And 'yes' we do have the Application > App Options > Application
    Configuration > Enable Session State ENABLED within the web site's
    properties within IIS 5 (with session timeout of 20 minutes).

    Thanks.
    April, Jan 23, 2009
    #1
    1. Advertising

  2. "April" <hostsafe_at_symbol_hotmail_period_com@this_is_my_email_address.com>
    wrote in message news:...
    >I have a Windows 2000 Server (SP4) with .NET Framework 1.1 (with hotfixes)
    >installed, along with .NET Framework 2
    >
    > I have a Delphi .DLL that interfaces with several .aspx files as part of a
    > member database. Each .aspx file contains categorized properties about
    > members. The first page is named profile1.aspx, the second page
    > profile2.aspx and so forth. NEXT and PREVIOUS buttons allow the user to
    > move back and forth.
    >
    > For some unknown reason, the session state is being lost as the
    > member/user clicks the NEXT and PREVIOUS buttons. My web.config file
    > contained the following lines:
    >
    > <sessionState
    > mode="InProc"
    > stateConnectionString="tcpip=127.0.0.1:42424"
    > sqlConnectionString="data source=127.0.0.1;user
    > id=sa;password="
    > cookieless="false"
    > timeout="20"
    > />
    >
    > Out of desperation we changed the mode from "InProc" to "StateServer" and
    > then turned ON the "ASP.NET State Service" from within the Services MMC
    > snap-in. After making this change, the session state is preserved between
    > pages.
    >
    > Might anyone know why session state would always be lost as the user moved
    > from .aspx to .aspx page with mode="InProc"?
    >
    > And 'yes' we do have the Application > App Options > Application
    > Configuration > Enable Session State ENABLED within the web site's
    > properties within IIS 5 (with session timeout of 20 minutes).
    >


    Bizarre. The only reason I can think of is that the application is shutting
    down between requests. Check the event logs to see if there is any
    indication of that. I take it you have Application Protection set to High
    (Isolated) for this app. In which case you will have COM+ application in
    Component Services, check this COM+ activation tab to see if anyone has
    fiddled with the idle timeout, ordinarily this will be set to remain running
    when idle but if someone has enabled an agressive idle timeout that could be
    your problem.


    --
    Anthony Jones - MVP ASP/ASP.NET
    Anthony Jones, Jan 23, 2009
    #2
    1. Advertising

  3. "Anthony Jones" <> wrote in message
    news:%23$...
    > "April"
    > <hostsafe_at_symbol_hotmail_period_com@this_is_my_email_address.com> wrote
    > in message news:...
    >>I have a Windows 2000 Server (SP4) with .NET Framework 1.1 (with hotfixes)
    >>installed, along with .NET Framework 2
    >>
    >> I have a Delphi .DLL that interfaces with several .aspx files as part of
    >> a member database. Each .aspx file contains categorized properties about
    >> members. The first page is named profile1.aspx, the second page
    >> profile2.aspx and so forth. NEXT and PREVIOUS buttons allow the user to
    >> move back and forth.
    >>
    >> For some unknown reason, the session state is being lost as the
    >> member/user clicks the NEXT and PREVIOUS buttons. My web.config file
    >> contained the following lines:
    >>
    >> <sessionState
    >> mode="InProc"
    >> stateConnectionString="tcpip=127.0.0.1:42424"
    >> sqlConnectionString="data source=127.0.0.1;user
    >> id=sa;password="
    >> cookieless="false"
    >> timeout="20"
    >> />
    >>
    >> Out of desperation we changed the mode from "InProc" to "StateServer" and
    >> then turned ON the "ASP.NET State Service" from within the Services MMC
    >> snap-in. After making this change, the session state is preserved
    >> between pages.
    >>
    >> Might anyone know why session state would always be lost as the user
    >> moved from .aspx to .aspx page with mode="InProc"?
    >>
    >> And 'yes' we do have the Application > App Options > Application
    >> Configuration > Enable Session State ENABLED within the web site's
    >> properties within IIS 5 (with session timeout of 20 minutes).
    >>

    >


    Oops I was thinking I was in a different NG. This advice makes sense still:-

    > Bizarre. The only reason I can think of is that the application is
    > shutting down between requests. Check the event logs to see if there is
    > any indication of that.


    However this advice applies to ASP not ASP.NET:-

    > I take it you have Application Protection set to High (Isolated) for this
    > app. In which case you will have COM+ application in Component Services,
    > check this COM+ activation tab to see if anyone has fiddled with the idle
    > timeout, ordinarily this will be set to remain running when idle but if
    > someone has enabled an agressive idle timeout that could be your problem.
    >


    On IIS5 ASP.NET runs in its own ASPNET_WP.exe process, you need to looking
    for whether that process is being knocked off for some reason between
    requests. IMO, ASP.NET doesn't still well on IIS5.

    --
    Anthony Jones - MVP ASP/ASP.NET
    Anthony Jones, Jan 23, 2009
    #3
  4. April

    April Guest

    > Oops I was thinking I was in a different NG. This advice makes sense
    > still:-
    >
    >> Bizarre. The only reason I can think of is that the application is
    >> shutting down between requests. Check the event logs to see if there is
    >> any indication of that.


    Anthony,

    Thanks, however, what "application" are your referring to? My Delphi DLL,
    or IIS? Both are applications, technically. It's not clear which you are
    referring to.

    Let me also comment that we have tried the DLL/.ASPX files on 2 other W2K
    servers. 1 owned by yours truly, another by a firm across the Pacific.
    Oddly, the very same thing happens on our second server, while on the server
    across the sea, it works perfectly without resorting to turning on the
    ASPNET State Service. Both are running IIS 5.

    > On IIS5 ASP.NET runs in its own ASPNET_WP.exe process, you need to looking
    > for whether that process is being knocked off for some reason between
    > requests.


    And how do I do that?

    Thanks
    April, Jan 23, 2009
    #4
  5. April

    April Guest


    >> Bizarre. The only reason I can think of is that the application is
    >> shutting down between requests. Check the event logs to see if there is
    >> any indication of that.


    The Event logs show nothing relevant.

    April
    April, Jan 23, 2009
    #5
  6. "April" <hostsafe_at_symbol_hotmail_period_com@this_is_my_email_address.com>
    wrote in message news:...
    >> Oops I was thinking I was in a different NG. This advice makes sense
    >> still:-
    >>
    >>> Bizarre. The only reason I can think of is that the application is
    >>> shutting down between requests. Check the event logs to see if there is
    >>> any indication of that.

    >
    > Anthony,
    >
    > Thanks, however, what "application" are your referring to? My Delphi DLL,
    > or IIS? Both are applications, technically. It's not clear which you are
    > referring to.
    >


    Application refers to the fact that the website or a sub folder thereof is
    marked as an application.

    > Let me also comment that we have tried the DLL/.ASPX files on 2 other W2K
    > servers. 1 owned by yours truly, another by a firm across the Pacific.
    > Oddly, the very same thing happens on our second server, while on the
    > server across the sea, it works perfectly without resorting to turning on
    > the ASPNET State Service. Both are running IIS 5.
    >
    >> On IIS5 ASP.NET runs in its own ASPNET_WP.exe process, you need to
    >> looking for whether that process is being knocked off for some reason
    >> between requests.

    >
    > And how do I do that?
    >


    Check process ID of the ASPNET_WP.exe after each request, if it varies then
    the process is bombing out after the first request for some reason.

    --
    Anthony Jones - MVP ASP/ASP.NET
    Anthony Jones, Jan 24, 2009
    #6
  7. April

    April Guest

    > Application refers to the fact that the website or a sub folder thereof is
    > marked as an application.


    Anthony,

    I've never heard such a thing. How can a website or a folder be marked as
    an application? This language is foreign to me...i.e, a folder being
    "marked as an application". How does a folder become marked as an
    application, or a web site become an application?

    > Check process ID of the ASPNET_WP.exe after each request...


    Could you be more specific as to HOW do I check the process ID. Using what
    tool or method?

    Thanks.

    April
    April, Jan 24, 2009
    #7
  8. April

    April Guest

    > Could you be more specific as to HOW do I check the process ID. Using
    > what tool or method?


    I suspect you are referring to using Task Manager to check the PID. Problem
    is...the server is remote, and I'm connected via Remote Terminal Services,
    meaning, TM doesn't show the PID for a service that launches on boot up.

    April
    April, Jan 24, 2009
    #8
  9. April

    April Guest

    > Check process ID of the ASPNET_WP.exe after each request, if it varies
    > then the process is bombing out after the first request for some reason.


    I have shut down the "ASP.NET State Service", changed its startup state to
    MANUAL. Changed the web.config mode = "InProc". Rebooted the server. I
    installed a process explorer that shows PIDs (even though I am connected
    remotely), ran the .NET apps (login.aspx -> profile1.aspx ) and the PID for
    aspnet_wp.exe is NOT changing. It remains constant after repeated F5
    refreshes. The PID prior to logging in remains the same PID after the user
    clicks NEXT on the profile1.aspx page. Yet the app is not taking the user
    to the 2nd page of the membership profile, but looping back to the login
    window (login.aspx). The only way to get to the 2nd page of the membership
    database (profile2.aspx) is to turn on "ASP.NET State Service" and change
    the web.config mode to "StateServer".

    April
    April, Jan 24, 2009
    #9
    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. Carpe Diem
    Replies:
    3
    Views:
    7,169
    Carpe Diem
    Feb 23, 2004
  2. Jeffry van de Vuurst
    Replies:
    0
    Views:
    2,103
    Jeffry van de Vuurst
    May 18, 2004
  3. MG
    Replies:
    2
    Views:
    1,800
  4. Med
    Replies:
    0
    Views:
    479
  5. Steph
    Replies:
    0
    Views:
    349
    Steph
    Nov 12, 2007
Loading...

Share This Page