A common approach to caching data in Web applications is to use an HTTP session. A business use case that spans multiple HTTP requests may create the need for caching in a Web tier. Once business use–case processing is completed, this cached data needs to be removed. Failure to do this may lead to memory leakage, which becomes noticeable when a user HTTP session continues for hours.

The Solution
The following terminology is used in subsequent sections:

• A use case is a sequence of steps performed by a user toward realization of a business requirement.
• A nested use case is the extension point from the base use case.
• The use case context represents the logical starting point of a use case.
• The handler is a server-side component responsible for processing HTTP requests.
• The cache element is an object, cached during use case processing.
• The navigation path is the sequence of handlers invoked when fulfilling a use case.

Rule 1: Only one use case is active at any instance: A user cannot process multiple use cases at a given instance.

Rule 2: A use case processing stage governs the cache element life cycle:

1. Start stage: New use case processing starts on completion or termination of prior use case processing. Cache elements that correspond to a prior use case are removed.
2. Intermediate stage: The user navigates to the next step or to a prior step of the use case. Forward navigation adds new cache elements; backward navigation may remove cache elements on an as-needed basis.
3. End stage: On completion of the use case, all accumulated cache elements are removed.

Rule 3: Handlers operate inside a use case context: User navigation dynamically builds a cache hierarchy tree with the handler and use case context as nodes and the cache element as a leaf. The handler node could hold a successor handler, cache elements, and a nested use case context. The use case context node holds a start handler. The root of the tree is the use case context.

Rule 4: Handlers operate on cache elements: Handlers create, read, and destroy cache elements.

Keeping these rules in mind, let's address the stated problem. We have conceptually built a cache hierarchy tree, which is the key concept to addressing the problem.

Step 1: Each request will go through the cache garbage collector
At the start of a new use case, the cache garbage collector removes all existing cache elements of the previous use case.

Figure 1 addresses the memory leakage problem. The introduction of the cache hierarchy tree removes tight coupling between handlers.

 

Step 2: Handlers navigate the cache hierarchy tree
A pointer is maintained to navigate the cache hierarchy tree. It points to the most recently processed node in the use case context. With the help of this pointer we can:

• Jump to a previous step
• Jump the nested use case context

Efficient memory handling at a granular level is achieved. At the same time, the decoupled handlers make future enhancements easier.

Solution Implementation
Cache Hierarchy Tree Design
The cache hierarchy tree is built using the GoF Composite pattern (see Figure 2). The use case context and handlers are the nodes; the cache element names are leaves; the actual cache element instances reside in the HttpSession.

 

Cache Hierarchy Tree Management
The "UserAppStateContainer" object holds the cache hierarchy tree. This container instance is stored in the user is HTTP session. "UserAppStateManager" helps manage the cache hierarchy tree.

Conclusion
The cache hierarchy tree empowers HTTP session garbage collection; however, this tree is also kept in the user HTTP session. So in a clustered environment it also needs to be replicated.