GUIDELINE 5.25
Using the Shared Memory
ABAP_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:
To implicitly store data from database tables temporarily using SAP
buffering, which can be determined when defining the tables in the ABAP
Dictionary
To explicitly store data clusters in the cross-transaction application
buffer using the EXPORT TO SHARED MEMORY or EXPORT TO
SHARED BUFFER statements
To explicitly handle (data) objects stored there using shared objects,
which are generated using the AREA HANDLE addition of the
CREATE OBJECT or CREATE DATA statements
ABAP_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.
ABAP_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 ):
You can store any number of (data) objects, including their mutual
interdependencies.
You can use (data) objects in the shared objects memory just like
objects in the internal session. Technically, the shared objects memory
can be considered an extension of the internal session during the time,
the memory is bound to it.
Multiple programs can simultaneously access the same memory area without
having to copy data to their own internal session.
Scenarios in which you can use shared objects efficiently include the
following:
Usage as a shared buffer
A shared buffer contains a large data set to which many users have read
access but which is changed rarely and is usually provided by a single
program.
Usage as an exclusive buffer
An exclusive buffer contains data that are accessed by only one program
but that is maintained for various programs across transaction
boundaries.
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:
A loader for creating and changing area instances
A broker for read access to area instances
Such wrapping ensures the following:
Central management of the internal session#s connection to the shared
objects memory and the corresponding locks
Central exception handling and respective fallback strategies (for
example, if the shared object#s memory overflows, you can ensure that
objects in the internal session are used without the using program
having to be notified of this).
Potential authorization checks
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.
"Get index page from data cluster
IMPORT index_html = index_html
FROM SHARED MEMORY docutables(...) ID ...
ASSERT sy-subrc = 0.
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.
"Get index page from shared memory
cl_docu_tables_broker=>get_index_table( ).
ASSERT cl_docu_tables_broker=>root->index_html
IS NOT INITIAL.
Documentation extract taken from SAP system, � Copyright SAP AG. All rights reserved