New ASP session issue when new window opened from WebBrowser control embedded in VBForm client

Discussion in 'ASP General' started by Vetrivel, Dec 11, 2003.

  1. Vetrivel

    Vetrivel Guest

    Application architecture : Develop interface between two existing
    systems,
    a. Enterprise CRM system
    b. Web based intranet system.

    Environment : Intranet
    Server : IIS and ASP.
    Script : VBScript and Javascript
    Client : 1. IE browser.
    2. VBForm embedded with WebBrowser control (MS Internet
    control - shdocvw.dll) called from another enterprise application.

    Web App : Uses server side business logic implemented in COM
    components. For each ASP session(starts with first ASP page user
    access and ends with last ASP page), server COM components are
    instanciated and held in session variables and liberally used in many
    of the ASP pages. In the last page, there is an "Exit" button, which
    when the user press, client side javascript closes the frames etc and
    invokes a destructor like Close.asp page (in a seperate window)that
    releases the session vars holding the COM component. Also, when
    window-close button(X) of IE is pressed same client side javascript
    invokes Close.asp pagein a seperate window.

    So far fine. No issues.

    Issue :

    When VBForm client is used, in the custom browser, if user press the
    "Exit" button to end the session, all the server side COM components
    held in Session vars are released immediately. No issues at all.
    However, if the user press the close button(X) of the VBForm, a new
    window spawned with Close.asp. However, the server side COM components
    are not released.

    Result : If website accessed through VBForm client, server side COM
    components are not released and hangs there for 20 minutes before they
    are released. Causes severe stress on the server, thus users getting
    slow response, at times requires a server reboot.

    Rootcause :

    It was discovered during rootcause analysis and further corroborated
    by many ofearlier questions in these forums and elsewhere is that,

    when a WebBrowser control client is used (as in the case here), the
    moment user close the window and new window is opened (by client side
    javascript) with Close.asp, IIS thinks it is a new session. So, it
    tries to release the COM components of the new session (though none at
    this point). Thus, the scope is lost for the orinigal session and its
    session vars hang there until session is timedout after 20 minutes.

    The crux of the problem is IE and WebBrowser control behaving
    differently w.r.t new windows. For IIS, with IE, the new window
    belongs to existing session but with Webbrowser control, the new
    window belongs to a new session.

    Ever elusive Solution : ?????

    So, with this detailed problem description , does any one have a
    solution to retain the original session even after opening a new
    window from VBForm client.

    Any solution(direct or alternate), workaround is very much
    appreciated.

    Thanks a lot for your help.
    -Vetri
     
    Vetrivel, Dec 11, 2003
    #1
    1. Advertising

  2. Vetrivel

    Ken Schaefer Guest

    When IE opens a new window (using File -> New Window, or a link that opens a
    new window, or javascript that opens a new window), the new window runs in
    the same process space as the old window. Thus it has access to the session
    cookie that stores the ASPSessionID, and returns it to the server. The
    server does it's work.

    It seems that you other application doesn't know about the ASPSession
    cookie, or if it does, isn't programmed to send that to the server. IIS then
    thinks that this is a new session.

    (ASP session state is maintained by the server sending the browser a cookie
    that holds the SessionID. The browser needs to return that to the server, so
    the server can associate the request with one of the sessions being
    maintained on the server. If the browser doesn't return the cookie, then IIS
    assumes that this is a new user, and starts a new session).

    Cheers
    Ken


    "Vetrivel" <> wrote in message
    news:...
    : Application architecture : Develop interface between two existing
    : systems,
    : a. Enterprise CRM system
    : b. Web based intranet system.
    :
    : Environment : Intranet
    : Server : IIS and ASP.
    : Script : VBScript and Javascript
    : Client : 1. IE browser.
    : 2. VBForm embedded with WebBrowser control (MS Internet
    : control - shdocvw.dll) called from another enterprise application.
    :
    : Web App : Uses server side business logic implemented in COM
    : components. For each ASP session(starts with first ASP page user
    : access and ends with last ASP page), server COM components are
    : instanciated and held in session variables and liberally used in many
    : of the ASP pages. In the last page, there is an "Exit" button, which
    : when the user press, client side javascript closes the frames etc and
    : invokes a destructor like Close.asp page (in a seperate window)that
    : releases the session vars holding the COM component. Also, when
    : window-close button(X) of IE is pressed same client side javascript
    : invokes Close.asp pagein a seperate window.
    :
    : So far fine. No issues.
    :
    : Issue :
    :
    : When VBForm client is used, in the custom browser, if user press the
    : "Exit" button to end the session, all the server side COM components
    : held in Session vars are released immediately. No issues at all.
    : However, if the user press the close button(X) of the VBForm, a new
    : window spawned with Close.asp. However, the server side COM components
    : are not released.
    :
    : Result : If website accessed through VBForm client, server side COM
    : components are not released and hangs there for 20 minutes before they
    : are released. Causes severe stress on the server, thus users getting
    : slow response, at times requires a server reboot.
    :
    : Rootcause :
    :
    : It was discovered during rootcause analysis and further corroborated
    : by many ofearlier questions in these forums and elsewhere is that,
    :
    : when a WebBrowser control client is used (as in the case here), the
    : moment user close the window and new window is opened (by client side
    : javascript) with Close.asp, IIS thinks it is a new session. So, it
    : tries to release the COM components of the new session (though none at
    : this point). Thus, the scope is lost for the orinigal session and its
    : session vars hang there until session is timedout after 20 minutes.
    :
    : The crux of the problem is IE and WebBrowser control behaving
    : differently w.r.t new windows. For IIS, with IE, the new window
    : belongs to existing session but with Webbrowser control, the new
    : window belongs to a new session.
    :
    : Ever elusive Solution : ?????
    :
    : So, with this detailed problem description , does any one have a
    : solution to retain the original session even after opening a new
    : window from VBForm client.
    :
    : Any solution(direct or alternate), workaround is very much
    : appreciated.
    :
    : Thanks a lot for your help.
    : -Vetri
     
    Ken Schaefer, Dec 11, 2003
    #2
    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. L. Chernov
    Replies:
    2
    Views:
    5,269
    vbbrad
    Aug 22, 2006
  2. albertly
    Replies:
    3
    Views:
    14,232
    Steven Cheng[MSFT]
    Feb 8, 2008
  3. L. Chernov

    .Net 2.0 - WebBrowser control embedded in IE causes problems

    L. Chernov, Jul 16, 2006, in forum: ASP .Net Web Controls
    Replies:
    1
    Views:
    354
    Alessandro Zifiglio
    Jul 18, 2006
  4. raj
    Replies:
    8
    Views:
    619
    J. Baute
    Apr 9, 2004
  5. Manjit
    Replies:
    0
    Views:
    237
    Manjit
    Jul 25, 2003
Loading...

Share This Page