SAP Clean Core Shared Memory (SHMA) & High-Performance In-Memory Caching Guide

1. The Problem with Repeated Database Roundtrips

In high-frequency ABAP Cloud environments—such as RAP determinations, validations, and custom BAdIs executing thousands of times per second—querying custom configuration tables repeatedly causes severe database overhead and CPU lock contention.

While standard table buffering exists for transparent tables, it is limited to specific key accesses and cannot cache complex internal objects, parsed JSON trees, or pre-calculated business rules. Shared Memory Objects (SHMA) solve this by storing complete object graphs in shared memory accessible across all user sessions and work processes on the application server.

2. Architecture of Shared Memory Areas

An SHMA configuration consists of three primary components:

• Area Root Class: The entry point object marked with the SHARED MEMORY ENABLED class attribute. It holds the cached internal tables and references.
• Generated Area Class: Generated by transaction SHMA (e.g. ZSHM_CONFIG_CACHE), exposing static methods like attach_for_read(), attach_for_write(), and invalidate_area().
• Area Instance Versioning: A concurrency mechanism that maintains an active version for ongoing readers while allowing a background writer to build a new version without causing deadlocks.

3. The Safe Consumer Pattern

To prevent lock starvation, consumers must attach for read, extract or reference the required data, and immediately detach:

TRY.
    DATA(lo_area) = zshm_config_cache=>attach_for_read( ).
    DATA(lv_value) = lo_area->root->get_value( 'TAX_RATE_EU' ).
    lo_area->detach( ).
  CATCH cx_shm_no_active_version.
    " Fallback or trigger automated build
ENDTRY.

4. Invalidation & Event-Driven Sync

When configuration data changes, calling zshm_config_cache=>invalidate_area() marks the active version as obsolete. The next read lock automatically triggers the if_shm_build_instance~build callback to refresh data from the database.