[WW-635] Components and HttpSession persistence/distribution

• Type: Bug
• Status: Closed
• Priority: 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

Environment

JBoss 3.2.5/Tomcat5

• Assignee: Donald J. Brown
• Reporter: Rolf Arne Corneliussen
• Created: 09/Sep/04 23:36
• Updated: 28/Oct/12 22:07
• Resolved: 14/Jun/06 12:36

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.