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.
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
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.