Discussions

EJB design: Sharing HTTP session across the applications

Bookmark and Share Get thread feed

  1. Sharing HTTP session across the applications (6 messages)

    • Posted by: Sharad Gupta
    • Posted on: August 28 2003 13:23 EDT
    We are developing a web application component that is intended to be used by other client web applications through runtime interaction - URL redirection. What are the options we have if we want to keep the client applications' HTTP sessions alive while users are redirected to our application temporarily? One option we are thinking is to stick the client applications' http sessions to ServletContext to keep them around. Please share your ideas.
    Thanks.
    Reply to this

    Threaded Messages (6)

  2. WAR's and EAR's, HttpSession's[ Go to top ]

    Do you have a single EAR or multiple EAR's?

    Do you have a single WAR or multiple WAR's?

    The Servlet 2.2 specification states:

    {{

    7.3 Session Scope

    HttpSession objects must be scoped at the application / servlet context level. The underlying mechanism, such as the cookie used to establish the session, can be shared between contexts, but the object exposed, and more importantly the attributes in that object, must not be shared between contexts.

    }}
    Reply to this Reply to original

  3. Separate EAR and WAR files[ Go to top ]

    These are two separate web applications with two sets of EAR and WAR files. My questions:
    1> Is it possible to for the component application to retain the session id of the client application and hand it over upon transferring the control to the client application?
    2> Is it possible for the client application, upon taking control, to restore its http session based on the session id?

    Thanks.
    Reply to this Reply to original

  4. Servlet Spec broken....[ Go to top ]

    This seems like broken behavior on the part of the specification
    to me. Anybody game for trying to work through the JCP and get
    this changed? I find the lack of ability to share sessions
    across contexts to be a real PITA.
    Reply to this Reply to original

  5. Or find a standard alternative...[ Go to top ]

    I should have added this to my previous message...

    Or, if there is some outstanding reason for not allowing the
    sharing of HttpSession objects, work through the JCP to come
    up with a different, better, standard way of sharing information
    between web-applications.

    There should be something better than
    relying on an external database, shared files, posting requests
    between servlets, etc. All of these strike me as some combination
    of slow, fragile, or just overly complicated.
    Reply to this Reply to original

  6. Sharing HTTP session across the applications[ Go to top ]

    I remember something about using a hidden frame that sends a refresh back to the client app at regular intervals (presumably less than the timeout). Never tried it myself tho'.
    Reply to this Reply to original

  7. Sharing HTTP session across the applications[ Go to top ]

    Can you use Web Services (SOAP) to call your web application and return the result back to the client?

    Is there any way you can install a small communication manager (Servlet) on your clients machine? If that is possible, the clients can forward the request to this communicator servlet. In this servlet, you can read the request parameters and session values and construct a HashMap (serializable) and then use HTTPUrlConnenction (HttpsUrlConnection for secure) to pass the control to your application. Advantage is that the control would be back to the Communicator Servlet after execution of your program and then you can try to restore the session of your client.

    Something that I have doen before and worked fine given my requirements.
    I am not sure whether this is going to work in your situation.

    Overhead is that any change to the communicator servlet would mean distrubution to all your clients.
    Reply to this Reply to original