Behandlung von Speicherengpässen
Das Shared Memory eines Applikationsservers ist eine begrenzte Ressource. Die ABAP-Laufzeitumgebung legt dort Programme, Programmdaten, Puffer usw. ab. Mit expliziter ABAP-Programmierung kann entweder auf Daten-Cluster in transaktionsübergreifenden Anwendungspuffern oder Shared Objects im Shared Objects Memory zugegriffen werden.
Wie viel Speicherplatz des Shared Memory von den unterschiedlichen Nutzern maximal belegt werden kann, wird durch Profilparameter statisch festgelegt. Die Transaktion ST02 (SAP Memory Management) zeigt die aktuelle Belegung des Shared Memory und die zugehörigen Profilparameter an.
Wenn der für das Shared Objects Memory zugeteilte Speicher beim Arbeiten mit Shared Objects überschritten würde, kommt es zur behandelbaren Ausnahme der Klasse CX_SHM_OUT_OF_MEMORY. Diese Ausnahme kann in verschiedenen Situationen auftreten:
● Beim Anlegen oder Ändern von Shared Objects im Shared Memory
● Beim Aufheben von Sperren mit DETACH_COMMIT
● Beim Anlegen von Sperren mit ATTACH_FOR_WRITE, ATTACH_FOR_UPDATE und sogar mit ATTACH_FOR_READ (wenn der Platz nicht mehr für die Verwaltungsinformationen ausreicht)
Aus diesem Grund empfiehlt es sich, die Ausnahme CX_SHM_OUT_OF_MEMORY für alle Zugriffe auf das Shared Objects Memory zu behandeln. Dies geschieht am einfachsten dadurch, dass alle Zugriffe auf Shared Objects, die idealerweise ohnehin nur innerhalb einer Verschalungsklasse stattfinden, auch nur in einer einzigen TRY-Kontrollstruktur stattfinden, in der diese Ausnahme behandelt wird. Wenn beim Behandeln der Ausnahme noch eine Änderungssperre auf das Gebiet bestehen sollte (was mit der Methode GET_LOCK_KIND des Gebietshandles festgestellt werden kann), sollte diese in der Regel mit DETACH_ROLLBACK aufgehoben werden.
Zur Behandlung der Ausnahme CX_SHM_OUT_OF_MEMORY kann eine geeignete Fallback-Strategie implementiert werden, die beispielsweise die benötigten Objekte im internen Modus anlegt und die bisherigen Inhalte aus dem Shared Memory in diese Objekte kopiert.