SAP NetWeaver AS ABAP Release 751, ©Copyright 2017 SAP AG. All rights reserved.ABAP - Keyword Documentation → ABAP Programming Guidelines → Architecture → Data Storage →
Using the Shared Memory
The shared memory of an application server is an highly important medium for buffering data with the goal of high-performance access. For this purpose, the shared memory can be used as follows:
Implement the explicit buffering in the shared memory using shared objects
Work with shared objects to explicitly use the shared memory for cross-program data buffering. The appropriate application scenarios are shared buffer and exclusive buffer. The access to shared objects should be wrapped in loader and broker classes.
For explicit access to the shared memory, shared objects (CREATE AREA HANDLE) provide the following advantages compared to the cross-transaction application buffer (SHARED MEMORY, SHARED BUFFER):
Scenarios in which shared objects can be used efficiently include the following:
The shared memory should not be used for different purposes, if, for example this results in many modifying accesses of parallel consumers, since the current locking concept does not support this.
Access to the shared memory should be encapsulated in specific classes, and application programs should access the shared memory using these classes only. Normally, there are two classes, which can also be combined into one class:
Such wrapping ensures the following:
This makes the application program more legible, more robust, and easier to maintain.
The following source code shows how an internal table index_table, which has been formatted elsewhere and buffered in the cross-transaction application buffer, is imported to a program. To store it locally, a local data object is required. Tasks like these can be performed more efficiently by using shared objects.
The following source code shows how an internal table index_table, which has been formatted elsewhere and buffered in the shared objects memory, can be accessed within program. By calling a get method, the corresponding broker ensures that its root attribute refers to a shared object that contains the table. A local data object is then not required to access the internal table in the program.