SAP NetWeaver AS ABAP Release 740, ©Copyright 2014 SAP AG. All rights reserved.
ABAP Keyword Documentation → ABAP Programming Guidelines → Architecture → Data Storage →Using the Shared Memory
Background
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, you can use the shared memory as follows:
Rule
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.
Details
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 you can use shared objects efficiently include the following:
You should not use the shared memory for different purposes, if, for example this results in many modifying accesses of parallel users, as the current locking concept does not support this.
You should encapsulate the access to the shared memory in specific classes, and application programs should access the shared memory via these classes only. Normally, there are two classes, which you can also combine into one class:
Such wrapping ensures the following:
This makes the application program more legible, more robust, and easier to maintain.
Bad example
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. You can carry out such tasks more efficiently if you use shared objects.
Good example
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. You then do not require a local data object to access the internal table in the program.