Ansicht
Dokumentation

ABENUSE_SHARED_MEMORY_GUIDL - USE SHARED MEMORY GUIDL

rdisp/max_wprun_time - Maximum work process run time   CL_GUI_FRONTEND_SERVICES - Frontend Services  
Diese Dokumentation steht unter dem Copyright der SAP AG.

Verwendung des Shared Memorys

Das Shared Memory einer ist ein äußerst wichtiges Medium für die Pufferung von Daten mit dem Ziel eines performanten Zugriffs. Zu diesem Zweck kann das Shared Memory unter anderem wie folgt verwendet werden:

• zur impliziten Zwischenablage für Daten aus Datenbanktabellen über die Tabellenpufferung, die bei der Definition der Tabellen im ABAP Dictionary festgelegt werden kann

• zur expliziten Ablage von Daten-Clustern im sogenannten transaktionsübergreifenden Anwendungspuffer über die Anweisungen EXPORT TO SHARED MEMORY oder EXPORT TO SHARED BUFFER

• zum expliziten Umgang mit dort abgelegten (Daten-)Objekten über Shared Objects, die mit dem Zusatz AREA HANDLE der Anweisungen CREATE OBJECT bzw. CREATE DATA erzeugt werden

Explizite Pufferung im Shared Memory über Shared Objects realisieren

Verwenden Sie Shared Objects, um das Shared Memory explizit zur programmübergreifenden Pufferung von Daten einzusetzen. Die dafür geeigneten Anwendungsszenarien sind Shared Buffer und Exclusive Buffer. Der Zugriff auf Shared Objects sollte in Loader- und Broker-Klassen verschalt werden.

Für den expliziten Zugriff auf das Shared Memory bieten Shared Objects (CREATE AREA HANDLE) folgende Vorteile im Vergleich zum transaktionsübergreifenden Anwendungspuffer (SHARED MEMORY, SHARED BUFFER):

• Es können beliebige (Daten-)Objekte inklusive ihrer gegenseitigen Abhängigkeiten gespeichert werden.

• Mit (Daten-)Objekten im Shared Objects Memory kann wie mit Objekten in der internen Sitzung gearbeitet werden. Technisch gesehen kann das Shared Objects Memory als eine Erweiterung der internen Sitzung angesehen werden, solange es an diesen angebunden ist.

• Mehrere Programme können gleichzeitig auf denselben Speicherbereich zugreifen, ohne dass Daten in die eigene interne Sitzung kopiert werden müssen.

Die Szenarien, in denen Shared Objects gewinnbringend eingesetzt werden können, sind:

• Verwendung als Shared Buffer

Ein Shared Buffer enthält eine große Datenmenge, auf die viele Verwender lesend zugreifen, die aber nur selten geändert und in der Regel von einem einzigen Programm zur Verfügung gestellt wird.

• Verwendung als Exclusive Buffer

Ein Exclusive Buffer enthält Daten, auf die zu einem gegebenen Zeitpunkt stets nur ein Programm zugreift, die aber über Transaktionsgrenzen hinweg für verschiedene Programme erhalten bleiben.

Von anderen Verwendungen des Shared Memorys, die beispielsweise viele ändernde Zugriffe paralleler Verwender zur Folge hätten, wird dringend abgeraten, da sie vom derzeitigen Sperrkonzept nicht unterstützt werden.

Der Zugriff auf das Shared Memory sollte in speziellen Klassen gekapselt werden, und ein Anwendungsprogramm sollte nur über diese Klassen auf das Shared Memory zugreifen. In der Regel handelt es sich um zwei Klassen, die aber auch zu einer Klasse zusammengefasst werden können:

• ein Loader für das Anlegen und Ändern von Gebietsinstanzen

• ein Broker für den Lesezugriff auf Gebietsinstanzen

Eine solche Verschalung sorgt für:

• eine zentrale Verwaltung der Anbindung einer internen Sitzung an das Shared Objects Memory und der zugehörigen Sperren

• zentrale Ausnahmebehandlung und entsprechende Rückfallstrategien (beispielsweise kann dafür gesorgt werden, dass bei einem Überlauf des Shared Objects Memorys auf Objekte in der internen Sitzung umgestiegen wird, ohne dass das verwendende Programm davon etwas merkt)

• eventuelle Berechtigungsprüfungen

Ein Anwendungsprogramm wird dadurch lesbarer, robuster und wartungsfreundlicher.

Folgender Quelltext zeigt wie eine interne Tabelle index_table, die an anderer Stelle aufbereitet und im transaktionsübergreifenden Anwendungspuffer gepuffert wurde, in ein Programm geladen wird. Für die lokale Speicherung muss ein lokales Datenobjekt vorgesehen werden. Eine solche Aufgabe kann über die Verwendung von Shared Objects effektiver erledigt werden.

"Get index page from data cluster
IMPORT index_html = index_html
       FROM SHARED MEMORY docutables(...) ID ...
ASSERT sy-subrc = 0.

Folgender Quelltext zeigt, wie auf eine interne Tabelle index_table, die an anderer Stelle aufbereitet und im Shared Objects Memory gepuffert wurde, in einem Programm zugegriffen werden kann. Der zugehörige Broker sorgt durch Aufruf einer get-Methode dafür, dass sein Attribut root auf ein Shared Object zeigt, das die Tabelle enthält. Im Programm ist kein lokales Datenobjekt für den Zugriff auf die interne Tabelle nötig.

"Get index page from shared memory
cl_docu_tables_broker=>get_index_table( ).
ASSERT cl_docu_tables_broker=>root->index_html
       IS NOT INITIAL.

SUBST_MERGE_LIST - merge external lists to one complete list with #if... logic for R3up   BAL_S_LOG - Application Log: Log header data  
Diese Dokumentation steht unter dem Copyright der SAP AG.

Length: 6154 Date: 20240523 Time: 104722     sap01-206 ( 93 ms )