Project

General

Profile

Feature #10280

AppServer Response Caching

Added by Artur Școlnic about 1 year ago. Updated about 1 year ago.

Status:
New
Priority:
Normal
Assignee:
-
Target version:
-
Start date:
Due date:
% Done:

0%

billable:
No
vendor_id:
GCD
case_num:
version_reported:
version_resolved:
reviewer:
production:
No
env_name:
topics:

History

#1 Updated by Artur Școlnic about 1 year ago

Overview

In the FWD layer, we have full control over AppServer requests and responses. This presents a clear opportunity: implement a caching mechanism for inquiry-type (read-only) requests.

My core assumption, the minimal invariant for caching, is that for the same input (method + parameters), the AppServer call returns the same response. This enables us to reuse cached results and avoid redundant backend calls, improving performance and reducing load.

Key Challenge: Cache Invalidation

Given the nature of our clients' applications, time-based expiration (TTL) is not suitable. The only reliable invalidation strategy is manual invalidation triggered by data changes.
To invalidate correctly, we need to know which AppServer methods update which database tables and what operations they perform. Having a mapping of:

Method -> List of affected tables

would allow us to selectively invalidate cache entries upon data changes, keeping the cache consistent and reliable.

High-Level Cache Flow

1. Intercept the AppServer request.
2. Identify if the request is an inquiry-type (read-only) method. Possible heuristics include:
  • Using parameter modes (input/output)
  • Checking the HTTP method of the client request, if available.
    3. Compute a cache key based on the method name, parameter modes, and actual parameters.
    4. Attempt to retrieve a cached response by this key. If found, return it immediately.
    5. If no cached response exists, invoke the AppServer method.
    6. After execution, if the method updates any tables, invalidate the cache entries related to those tables.
    7. Cache the new response for future use.
Cache Structure
The cache should have at least two levels:
  • One keyed by the method name (or signature).
  • Another keyed by the method parameters.
Open Problems
  • How to reliably detect inquiry vs. update methods (point 2)?
  • How to track which tables are updated by which methods (point 6)?
Potential Approaches to Track Updates
1. Static Analysis at conversion Time
  • Add hints by detecting table-altering operations inside each procedure/method.
  • Dynamic queries and procedure calls will be especially challenging.
2. Runtime Tracking
  • At runtime, track every table update along with the originating method name.

Goal
Build a reliable map of methods to tables they modify, enabling precise cache invalidation and consistent, efficient caching.

Also available in: Atom PDF