Struts 2
  1. Struts 2
  2. WW-635

Components and HttpSession persistence/distribution

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Won't Fix
    • Affects Version/s: WW 2.1.1, 2.0.0
    • Fix Version/s: 2.0.0
    • Component/s: Build Management
    • Labels:
      None
    • Environment:

      JBoss 3.2.5/Tomcat5

      Description

      Short description:

      If using the IoC stuff of WebWork/XWork and a HttpSession is serialized, the Session scoped component manager is also serialized, and by implication also the application scoped manager is serialized. If the HttpSession is then deserialized in another JVM than it was created, it will bring with its own the application scoped manager, and not use the manager in its current application context.

      Elborated:

      The application scoped component manager is bound to a Servlet context, which have the following properties:

      • Its lifespan is linked to the web-application lifespan. limited by the JVM
        lifespan
      • It is associated with only one JVM
      • It is not supposed to be serialized

      The session component manager is bound to a HttpSession, which have a
      different set of properties:

      • Its lifespan is linked to the HttpSession lifespan, and HttpSessions can live longer than its hosting JVM
      • It can be transferred to another JVM after construction
      • It can be serialized

      The relationship between the application manager and the session manager is kind of static. The session component manager gets its parent application manager when it is created and is never changes after that. If the HttpSession it is bound to outlives the application or gets transferred to another JVM, it takes its application manager with it (because serialization follows the reference to its fallback app. manager).

      This leads to the following problems:

      • Our transferred session will have its own application manager that is different from the manager bound to its new servlet context
      • The application component manager has a different set of properties that does not include transfers between JVMs.

      The relationship could be handled more dynamically, so a
      session manager should drop the reference to its application component
      manager (that is, the fallback) when it is about to leave a JVM. When the session manager is recreated in another JVM, it should be connected to the application component manager that is the manager in its new JVM.

        Activity

        Hide
        Don Brown added a comment -

        The XWork IoC framework was deprecated in XWork 1.1 and will probably be removed completely in 2.0. Still, if you find this a problem in other areas of Struts Action 2, please open a new ticket as this is an important problem. Thanks.

        Show
        Don Brown added a comment - The XWork IoC framework was deprecated in XWork 1.1 and will probably be removed completely in 2.0. Still, if you find this a problem in other areas of Struts Action 2, please open a new ticket as this is an important problem. Thanks.
        Hide
        Rolf Arne Corneliussen added a comment -

        That's OK. We now use Spring as the IoC container, effectively trading one issue for another

        Show
        Rolf Arne Corneliussen added a comment - That's OK. We now use Spring as the IoC container, effectively trading one issue for another
        Hide
        Patrick Lightbody added a comment -

        Rolf,
        I don't think that I'll be able to get to this before 2.2 (we really need to get a release out). But I did want to let you know that you no longer NEED the session component, so a workaround is to just use request and application for now. Not great, I know, but this is a hard problem. Spring hasn't even started to tackle it

        Show
        Patrick Lightbody added a comment - Rolf, I don't think that I'll be able to get to this before 2.2 (we really need to get a release out). But I did want to let you know that you no longer NEED the session component, so a workaround is to just use request and application for now. Not great, I know, but this is a hard problem. Spring hasn't even started to tackle it
        Hide
        Patrick Lightbody added a comment -

        I have been looking at better ways to handle this, mainly by using transient references and better component management detection (ie: re-initialize if the object is null)

        Show
        Patrick Lightbody added a comment - I have been looking at better ways to handle this, mainly by using transient references and better component management detection (ie: re-initialize if the object is null)

          People

          • Assignee:
            Don Brown
            Reporter:
            Rolf Arne Corneliussen
          • Votes:
            2 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development