Show TOC Anfang des Inhaltsbereichs

Hintergrunddokumentation Shared Objects - Hinweise zur Verwendung  Dokument im Navigationsbaum lokalisieren

Verwendungszenarien

Der Zugriff auf  Shared Objects wird durch Sperrmechanismen geregelt. Die einzelnen Sperren sind als Verwaltungsinformationen mit den Gebietsinstanzen im Shared Memory abgelegt und werden beim Zugriff über Gebietshandles gesetzt und ausgewertet. Die Arbeitsweise der Sperren geht von folgender Verwendung von Shared Objects aus:

      Szenario 1 – Verwendung als Shared Buffer

Ein Shared Buffer ist eine Datenablage, die nur selten (einmal pro Tag bis maximal einmal pro Stunde) und in der Regel nur von einem einzigen Verwender geändert wird. Die Datenmenge kann sehr groß sein. Im Allgemeinen greifen viele Verwender gleichzeitig lesend auf einen Shared Buffer zu. Ein typisches Einsatzgebiet eines Shared Buffers ist die Ablage eines Katalogs.

      Szenario 2 – Verwendung als Exclusive Buffer

Ein Exclusive Buffer ist eine Datenablage, auf die nur ein Verwender schreibend und lesend oder – in seltenen Fällen – ein Verwender schreibend und ein anderer Verwender lesend zugreift. Die in einem Exclusive Buffer abgelegten Daten sollen aber längerfristig, d.h. über die Lebensdauer eines Programms hinweg, zur Verfügung stehen. Ein typisches Einsatzgebiet eines Exclusive Buffers ist die Ablage eines Warenkorbs, der erst vom Käufer gefüllt und später vom Verkäufer ausgelesen wird.

Eine allgemeine Shared-Memory-Programmierung ist nicht vorgesehen. Die derzeitigen Sperrlogik erlaubt es nicht, spezifische Sperren für folgende Anforderungen zu setzen:

      Viele parallele Schreib- und Lesezugriffe

      Häufige Schreibzugriffe

      Unterteilung in änderbare und nicht-änderbare Bereiche

Die ersten beiden Punkte sind zwar technisch möglich aufgrund der Sperrlogik aber praktisch nicht durchführbar, da die meisten Zugriffe abgewiesen würden.

Verschalung

Es wird empfohlen, in Anwendungsprogrammen nicht direkt auf das Shared Objects Memory zuzugreifen, sondern die (Lese-)Zugriffe auf die Shared Objects in einer Verschalungsklasse zu verschalen, auf deren (GET-)Methoden die einzelnen Programme zugreifen. Als Verschalungsklasse kann z.B. die Gebietskonstruktorklasse verwendet werden.

Die Verschalung bietet folgende Vorteile:

      Zentrale Verwaltung eines Gebiets im Shared Memory

      Ein Anwendungsprogramm muss sich nicht um Gebietshandles und Sperren kümmern.

      Zentrale Verwaltung der Sperren

      Möglichkeit zur Implementierung zentraler Berechtigungsprüfungen

 

Einschränkungen

Zurzeit gelten die folgenden Einschränkungen:

      Auf 32-Bit-Systemen steht auf Grund des beschränkten Adressraums nur ein geringer Speicherbereich zur Ablage von Shared Objects zur Verfügung. Deshalb sind Shared Objects auf 32-Bit-Systemen nur bedingt einsetzbar

      Über Datenreferenzen referenzierte Datenobjekte können seit Release 7.0 im Shared Memory abgelegt werden. Dabei besteht die Einschränkung, dass der dynamische Typ nicht zur Programmlaufzeit erzeugt worden sein darf. Ein direkter Bezug auf Datenelemente und Tabellentypen des ABAP Dictionary darf seit Release 7.10 vorgenommen werden.

      Speicherengpässe im Shared Objects Memory können seit Release 7.10 behandelt werden, und führen zur Ausnahme CX_SHM_OUT_OF_MEMORY. Vorher kam es zu unbehandelbaren Laufzeitfehlern.

      Der Speicherverbrauch von Shared Objects im Shared Memory kann noch nicht durch den  Memory Inspector überwacht werden.

      Es gibt keine Speicherbegrenzung auf der Ebene logischer Gebiete, die im Allgemeinen aus vielen Gebietsinstanzen bestehen. Gegenwärtig gibt es Speicherbegrenzungen nur für einzelne Gebietsinstanzen.

      Die Lebensdauer von Gebietsinstanzen kann nicht an die Lebensdauer von Benutzersitzungen, externen Modi oder Transaktionen gebunden werden. Gegenwärtig leben Gebietsinstanzen grundsätzlich so lange wie die Applikationsserver-Instanz.

Ende des Inhaltsbereichs